lightning quick woody+1 release scenarios (was Re: Wishlist for woody+1)

[Joey Hess <joeyh@debian.org>]

I wrote in response to Colin Watson:
> > > - release 2 months after woody
> > 
> > Is anyone willing to maintain boot-floppies for another release? If not,
> > one of the best ways to achieve this is to get enough people working on
> > debian-installer to make it stable as quickly as possible.
> 
> Yes, exactly. I'd love nothing more than to see woody+1 in 2 months, but
> the boot-floppies crew is emphatic that it's End Of Life, and probably
> wouldn't appreciate another release worth of work (it's always 500% more
> work than you'd expect to prepare boot-floppies for release) and no
> replacements are production quality yet.

Here are a few scenarios that might be worth thinking about if we want
to seriously pursue a very quick successor to woody with limited updates.

Scenarios:

1. Come up with a well-defined criteria for what packages in the release 
   can be updated. Something like:
   
      Large, important, often-requested packages that have been well-tested
      upstream, and have a minimal impact on the rest of the system, and
      none on the tasks and boot-floppies system.

   Take care to not effect boot-floppies at all; boot-floppies will not be
   revved for this release (unless the boot-floppies people independantly
   devide to do a minor rev for a major bug or new kernel like they might
   do for 3.0r2 anyway.)

   First 2 weeks: Apply criteria and select packages to be upgraded for
                  release. Develop.
   Second 2 weeks: Develop.
   Second month: Test.

   Testing possibilities:

   a. Keep testing frozen after release except for said manual updates.
      Test testing. Severe downside: We're all tired of testing being
      freaking frozen, already.      
   b. Open testing for development of woody+2, put manual updates direct
      into stable. Downside: Mo testing! Probably crazy.
   c. Add another branch, as proposed elsewhere, put updates into it.
      Downside: Who knows how long it would take to add such a branch.
   d. Just test a random apt repository somewhere, but that would
      limit the testing it received. It didn't work all too great for
      slink-and-a-half..

   Potential problems:

   a. The upgraded packages depending on newer versions of lots of other
      stuff, or requiring updates to dependant packages (mozilla and galeon,
      etc), leading to many necessary changes despite the tight focus.
   b. Changes like eg, kde 3 might require changes to the task system.
   c. The planned 2 months goes over, and we're faced with trying to
      continue with increasingly outdated packages, or giving up and
      dropping the plan.
   d. Interference with woody+2 and long term development.
   e. Issues with the CD creation could easily crop up.
   f. The my-minor-bug-in-my-insignificant-package-is-RELEASE-CRITICAL
      syndrome.

2. Go on much as we have before, trying for a whole release with the
   testing system in place, so we have a better baseline. Plan a freeze in
   4 months, or 6 months, push that back.. you know what happened with
   woody, just add trying to get a new installation system to it in place
   of crypto-in-main or another major woody blocker. Release in 1 to 2.5
   years. Bah.

3. Gather a team of 5 to 10 boot-floppies hackers (who are already familiar
   with it), to maintain boot-floppies as any changes come up. Use a
   criteria similar to in 1., but we don't care if changes impact the boot
   floppies.

   First 2 weeks: Decide what packages get updated.
   Second 2 weeks: Development.
   Second month: Testing and any necessary boot-floppies, tasks, etc
                 changes.
   Third month: Testing, as 1.

   Potential problems as 1; 1.b. no longer a problem, 1.c. and 1.d. even more
   of a potential problem.

4. Gather a team of 20 to 40 determined people and crank through
   debian-installer or PGI; get it ready for release. This will take at
   least a couple of months, during which time the rest goes as in 3.
   Release after maybe 4 or 5 months.

   Potential problems:
   
   a. We can't really estimate how long it would take to finish either 
      installer enough. Estimates will be wrong.
   b. Testing will take longer.
   c. Documentation updates called for.
   d. Changes to debian-cd called for.
   e. Archive changes will be required for d-i.
   f. 1.c., 1.d., and 1.f. remain as problems.

5. Ditch stable and "release" testing every week or so.

   Problems: Far too many to list.

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org