I'm seeing lots of post-sarge development in trunk now and most of it
cannot be uploaded to unstable because of the lacking t-p-u queue. I'm
concerned that this might lead to trouble later, if we have large masses
of untested stuff all flooding into unstable. And certian other
development is just stalled. (For an expanded description of these
problems, see http://kitenet.net/~joey/blog/entry/d-i_stall-2005-04-13-00-56)
Anyway, I propose that we set a date after which we will open unstable
for post-sarge d-i development, even if sarge is not released or the
t-p-u queue is still not yet set up. I think that May 1st would be a
good date.
The potential problems this could cause include:
- We find a bad problem in rc3 after May 1st, but the fixed udeb in
unstable has many post-sarge changes and is not appropriate for
sarge. t-p-u still cannot built it for all arches. So we have some
choices how to fix it, none ideal
a) revert the changes in the unstable udeb and get that into testing
then put the post-sarge changes back
b) upload it to t-p-u and manually make the N manual builds needed
for the arches that don't yet build t-p-u
c) keep a RC bug open on the udeb in testing and do nothing
until t-p-u is finally functional, then upload the fix
- We find a bad problem in rc3 after May 1st, which only affects sarge;
unstable has rewritten all the code already. Now we have to test the
fix for sarge, and it's hard to test it widely until the fix has
gotten into sarge (d-i cannot pull udebs from t-p-u). The fix ends up
breaking three other things, and we're in a nasty cycle of making
unstable-type uploads to testing and forcing them in without much
testing.
(This situation is already possible with some of the branched
packages in testing.)
- Some post-sarge d-i changes may call for branching of other things,
like debian-cd.
- Any others?
I think these are real potential problems, but they're solvable and
other fixes to the problems I alluded to in my first paragraph (such as
making d-i use experimental or such) would probably take more work.
Also, rc3 has had a long enough soak period already with no really RC
issues, and in two weeks more it seems unlikely we'll still be finding
RC issues with it.
So I think that resuming development in unstable is worth it, but I
really want to hear the opinions of the release managers and others
first.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature