Re: Some questions for the DPL candidates

[Sam Hartman <hartmans@mit.edu>]

>>>>> "Ben" == Ben Collins <bcollins@debian.org> 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.