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

PROPOSAL: preparation for freezes, release coordination

My take on the situation is that there are two reasons for why the
freeze takes a long time.  The first is just fixing the release
critical bugs -- this commonly receives a lot of attention from this
list.  The second is coordination between all the elements which are
required for release (boot-floppies, cd, archive mgmt, porters, the QA
team, testers, security team).

* Release Critical Bugs

With respect to fixing release critical bugs, I think there are two
components to lowering this as a big problem.  The first, as pointed
out, is to *not* try to cram heavily broken things into unstable just
prior to freeze, and it just requires a little self-discipline from

The second solution for fixing release-critical bugs is a revived and
healthy Debian QA group.  I believe Joey is trying to revive this, and
I wish him the best of luck.

Looking back at the slink freeze, I think we had two big problems
which slowed us down by about a month: new X Window System packages,
heavily broken, and the libc problems.  I don't wish to cast any blame
on the package managers for this -- I just hope we don't have a
repeat, and I hope everyone learned a lesson from that.

* Release Coordination

As we add more and more ports, the issue of release coordination
becomes more difficult.  There is very complex interactions between
the particular state of the Debian frozen archive, the boot-floppies,
the CD images, ports, etc.  For instance, a fix for a certain problem
in i386 might really make life hell for the ports.  No forum currently
now for the discussion of the actual freeze area itself, what problems
must be fixed for proper implementation/testing of boot-floppies or
CDs, conflicts between the frozen archive for different architectures
(these really suck), which architectures are release candidates, etc.

I propose that we create a new list (argh, yet another list!),
'debian-release'.  Next, we ask that representatives from all
interested teams (including boot-floppies, cd, archive mgmt, porters,
the QA team, testers, security team) be subscribed to the list.  This
would be a low-volume list for the increased communication between
these teams.  The consensus reached on this list must be implemented
in an prompt fashion, i.e., moving packages into the archive.

Looking back at the slink release, I think we went into the freeze
with no proven facility to deal with multiple CDs, and this cause
significant delays.  Numerous conflicts between the ports arose.  I
also think that porters, boot-floppies members, and the CD team felt a
bit helpless in having a say about what needed to go into the frozen


.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Reply to: