And we're done, finally.
Remember that Frans Pop assisted with this release and should now know
everything he needs to know to make the next release happen, hopefully
in record time with all sorts of improvements. I'll still be around to
assist him.
That took somewhat longer than expected. We have been preparing this
release ever since (before) the release of sarge, and for at least the
past 1.5 months have been in almost-ready-to-release mode with one issue
and then another blocking things. For what it's worth, here is my top
ten list of things that make d-i releases take much too long to do.
1. Far too much time was spent not able to work on the installer and
having to chase various debootstrap, apt, desktop task, etc
breakage. Many maintainers make changes without considering the
ramifications, and often the ramifications arn't clear until
something has broken.
2. Not much attention is paid to keeping images (d-i and CD) building
on a day-to-day basis for all arches, so it's rare to have a day when
all of d-i and the CD images build successfully. This has to happen
at least once to get a release out, and large amounts of time are
spent just bringing breakage to porters'/maintainers' attention.
3. Some arch always fails to build a key component due to {buildd
being down, toolchain being broken, gremlins}, or a key component
is built and not uploadded from the buildd for a week. This cost us
probably upwards of three weeks of time in preparing this beta. The
amazing thing is that we released for all arches except s390
despite this.. mostly because it was rarely just one arch that was
delaying things.
4. The archive updating only once per day continues to limit the pace
of d-i development substantially. I still think that updating
twice a day would nearly double our development speed.
5. Building a full set of CD/DVD images and getting them on the web site
takes approvimatly 1.75 days, which, repeated a few times, added +- a
week onto the prep time for this beta.
(OTOH, that's much better than the 1 week it used to take.)
7. The new ultra-careful udeb syncng to testing to make sure to not
violate some letter of the GPL procedure slowed things down quite
a bit, partly due to 3. above, and partly due to being manual and
needing to be done over and over until we got all the udebs synced.
The procedures also rely on humans to spot udeb dependency issues,
which doesn't work. We need udeb support in britney.
6. debin-installer packages have to be manually processed by
ftp-masters, which can easily waste a few days. It's like going
through NEW for every minor release of a package. This should be
easily automated.
8. The screwed up udeb library dependency situation makes the
debian-installer build process much more fragile than it needs to
be, aggrivating 2. above and probably blocking progress on 7. above.
I have given up on getting any kind of answer for when the patch that
allows this to be resolved will be accepted into dpkg-dev.
9. From day to day, d-i generally gets insufficient testing for anything
outside the mainsteam install-{i386,powerpc,amd64}-from-cd, so we
end up getting deluged with problems when people realize a release is
about to happen. Expending the d-i test lab to cover more
architectures (and un-breaking the parts of it that are currently
broken) would help, but we also need more people to try the corner
cases that can't be automated from time to time; and we need to add
more automated regression testing.
10. It takes an average of six hours to update the Debian website,
leading to fun decisions like "do I commit the web site changes
now, assuming we will have managed to fix issues in 6 hours time,
or do I delay the release by another day?"
Note that if each of these things delay a d-i release by just 3 days,
which most of them do, that's one full month added to the release
process. I'd put the actual cumulative delay closer to two months this
time around.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature