[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The sarge release disaster - some thoughts



On Tue, Mar 15, 2005 at 07:40:09PM -0500, Joey Hess wrote:
> Adrian Bunk wrote:
> > Not after October 1st 2003 it sould have been clear that the progress 
> > of the installer wasn't as good as expected. This was 2 months before 
> > the announced release date.
> > 
> > What would have been a second plan?
> > Nobody likes boot-floppies.
> > But considering the choice between releaseing Debian 3.1 with the new 
> > installer in 2005 or releasing Debian 3.1 with boot-floppies in 2003, it 
> > might have been possible finding some Debian developers hacking 
> > boot-floppies to use them for Debian 3.1 .
> > 
> > The new installer would have been ready in time for Debian 3.2 .
> 
> IIRC when we did this for potato, getting the woody boot-floppies
> updated to work with the new kernel and potato took something on the
> order of 6 months. Do not make the mistake of thinking the boot-floppies
> were maintainable. Expecting them to be ready in two months would be
> impractical.

Someone of the installer people must have promised ajt that the 
installer was ready at the dates in the release announcement (or ajt 
wouldn't have announced these dates) - and it should have been clear two 
months before the announced release date that this wouldn't work.

Let me give the worst possible second plan:
Release with the original potato boot floppies.

I'm not talking about elegant solutions.
I'm talking about hacks to not let the delays in the installer after the 
release announcement delay the whole release by a year or more.

> Also, bear in mind that if we'd have done that, then we would still be
> where we are right now, but would not have the debian installer ready to
> release with sarge.

It might have delayed the work on the new installer.

But delaying Debian 3.2 by a few months if this would have enabled a 
release of Debian 3.1 in 2003 doesn't sound like a very bad tradeoff for 
your users.

> > What would have been a second plan?
> > Use testing-proposed-updates.
> 
> testing-proposed-updates is _still_ missing autobuilders.

Please correct me if I'm misunderstanding things:

t-s required some infrastructure changes that took at about half a year.

Getting missing autobuilders for t-p-u is a task that requires manpower 
and perhaps even money, but if it's _the_ showstopper, it should be 
resolvable within a few weeks or even days.

So this might have reduced a half a year delay to a few weeks delay.

> > Consider a MUA maintained by a MIA developer with the following bugs:
> > - #1 missing build dependency (RC)
> > - #2 MUA segfaults twice a day (not RC)
> > 
> > Consider the two possible solutions:
> > 1. a NMU fixing #1
> > 2. - ensure that the maintainer is MIA
> >    - orphan all packages of the MIA maintainer
> >    - new maintainer adopts MUA
> >    - new maintainer fixes both bugs
> > 
> > The first solution has a quick positive effect on the "RC bug count" 
> > metric.
> > The second solution looks worse in this metric, but it's actually better 
> > for the users of Debian.
> 
> I doubt that many people NMU for RC bugs without also looking at the
> recent release history of the package and checking to see what other bad
> bugs the package may have.

The first example that comes into my mind is the info package where the 
two NMUs didn't fix the many open segfault bugs (e.g. #259561 contained 
a trivial patch ACK'ed by upstream being one and a half months in the 
BTS before the latest NMU - note that this NMU was even done by a 
Release Assistant).

This shouldn't be a personal offense against the person who did this 
particular NMU - it's simply the first example coming into my mind.

> see shy jo

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed



Reply to: