>>>>> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> On Thu, Mar 08, 2001 at 12:24:29AM -0500, Branden Robinson
Ben> wrote:
>> On Tue, Mar 06, 2001 at 11:45:58PM -0500, Ben Collins wrote: >
>> On Tue, Mar 06, 2001 at 10:31:00PM -0500, Branden Robinson
>> wrote: > > > > > * What do you think will be the three major
>> problems Debian will face > > > over the next year or two? > >
>> > > * version skew between our many supported architectures
>> hamstringing our > > package pools > > a) Testing ensures that
>> we can release with little or no version skew > b) Your
>> assertion makes it appear as if the architectures are at fault,
>> > when in fact 95% of the time (I have stats) build failures
>> are due to > the package, and not specific to an arch.
>>
>> I do not see how your inference follows from my statement.
>>
>> The current implementation of testing does indeed ensure that
>> we can release with little or no version skew, but it doesn't
>> necessarily result in less buggy packages. Take the case of
>> XFree86 4.0.2-1. It didn't have RC bugs, and it didn't have
>> build errors. It just didn't get built for all 6 architectures
>> for well over a month. Even then, Anthony Towns had to force
>> it in. (Now, of course, the testing archive has been clobbered
>> and XFree86 is gone again -- this is so mortifying that my
>> emotional continuum has wrapped around and I have to laugh
>> about it.)
Ben> Releasing is the point, and I do believe that testing will
Ben> create a more up-to-date release than we have had in the
Ben> recent past. Just because X (one of the largest builds for
Ben> the buildd's) had issues, doesn't make it so for all other
Ben> packages.
But when X fails to install into testing it really does hurt the
release; many packages in Debian depend on X. When X, Perl (and thus
debconf) , etc failed to go into testing, it did cause a significant
delay.
Yes, there are many maintainer problems, but there are also
port/release problems. The m68k buildd was using a broken mirror
apparently from some time in Decemeber until February 8 and even
though questions were asked on debian-devel and debian-68k, the
response took a long time.
We can't just focus on the port/release problems, and we can't just focus on
the maintainer issues; we need to solve both.
>> > The other 5% can be due to toolchain issues, or just plain
>> old oddities > in our complex dist that requires the buildd
>> operator to actually > manually build the package (IOW, no bug
>> at all, just a manual build).
>>
>> It doesn't really matter what the causes are. They all take
>> manpower to fix, and as we try to release for something like 10
>> architectures simultaneously, we run the risk of ending up in
>> the same boat we've always been; testing is so far out of date
>> that it doesn't really matter that it wasn't that way because
>> we were frozen for 9 months.
Ben> Of course it matters what the causes are. It is a direct
Ben> relation to solving it.
I think what Branden was trying to say is that the importance of the
problem is independent of the cause, but dependent only on the result.
I think he has identified a valid concern--packages lots of stuff
depends on not getting into testing quickly, and you have identified a
different problem--maintainers not fixing their packages.
It seems reasonable for a DPL candidate to say they are going to try
to fix both of these.
