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

proposal: reopen unstable to development, may 1st

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

   (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

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: