On Sun, May 26, 2002 at 09:46:01PM -0400, Joey Hess wrote:
> 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.
Here are some caveats.
> 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.
So no gcc 3.1, no new KDE or Gnome (which I would assume would have a large
impact on the tasks), no new dpkg.
> 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.)
So this probably also means we have another 2.2 based release, without
particularly good support for non-English users as far as the installer
goes. Depending on how strict you want to be (and for a two month release
cycle you're going to have to be /very/ strict) it probably means not
making aptitude or similar available for the initial install.
> First 2 weeks: Apply criteria and select packages to be upgraded for
> release. Develop.
> Second 2 weeks: Develop.
> Second month: Test.
Let me just register my doubts at that having any chance of working, too.
> 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.
...and it's been barely four weeks, let alone the two months which is
the *best possible* estimate for the above.
> b. Open testing for development of woody+2, put manual updates direct
> into stable. Downside: Mo testing! Probably crazy.
This assumes you have someone willing (and able) to do this. I believe
Joey's (Martin Schulze, not Joey Hess) already indicated he wants to
keep stable updates as simple as possible, and I'm much more interested
in working on all the new development I've been putting off trying to
get woody released.
> 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..
If unstable/testing's where all the interesting stuff is, and whatever
your new area is called is liable to break regularly, you're probably
going to find it hard to get testers no matter what you do. (*shrug*)
> Potential problems:
> f. The my-minor-bug-in-my-insignificant-package-is-RELEASE-CRITICAL
> syndrome.
There's also the my-horrible-bug-in-my-insignificant-to-most-people-but-
crucially-important-to-me-and-foo-and-bar syndrome. It's not really very
good to make a release that not only has known bugs, but it's worse when
we have fixes for those bugs. Obviously that shouldn't stop us, but it
seems better to at least give people a chance of getting their fixes in.
> 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.
I'm leaving following up to this in detail 'til we've finished woody. I'm
not so pessimistic.
> 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.
It seems unduly optimistic to imagine that's possible.
> 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:
> e. Archive changes will be required for d-i.
More of them?
> f. 1.c., 1.d., and 1.f. remain as problems.
On the upside: with a maintainable installer we don't have to keep
worrying about who the hell we're going to get working installation
tools every cycle.
> 5. Ditch stable and "release" testing every week or so.
> Problems: Far too many to list.
Most particularly that we don't have working installation media until
a few weeks before we release stable. I can't imagine it'd be much fun
to have the only way to install Debian four years from now to be using
a woody CD...
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpdQsNLaM3Ea.pgp
Description: PGP signature