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

Re: potato late, goals for woody (IMHO)



On Sun, Apr 30, 2000 at 03:31:10PM +0200, Adrian Bunk wrote:
> potato has nearly no new packages since january. If woody will be frozen
> one or two months after potato is released there's a change to release
> woody less then one year after the freeze of potato.

Why would we want to release woody less than a year after potato's
*frozen* let alone released?

We've already tried this with slink, less time spent between freezes
doesn't lead to less time within a freeze. All it does is cut out x
months of development time.

Consider two options. If we release Jan 1st 2001, after, say, a four month
freeze we'll have been adding new stuff for the three months June, July
and August. As well as whatever people have added to woody already. So
we'll get a bunch of new packages, a few architectural cleanups in
various packages, and some bugs fixed.

Suppose, alternatively, that we release six months later than that, ie
around July 1st 2001. After a four month freeze, that means we get to
develop new stuff from June through February, which gives us around nine
months. ie, by waiting twice as long, you get three times the amount of
new and interesting stuff added into Debian.

In addition, short releases don't really serve anyone's best interest.
IMAO (and without having done even a casual survey, or anything), there
are three sorts of Linux users (hi Bdale ;): those who don't really care
about getting the latest gizmos, and just want something that'll work
and keep working with minimal though -- these are the people who should
be using stable; people who are into the whole free software thing and
want to run the latest of everything and get hit by enough bugs that
they can recount exciting war stories with their friends -- these are
the people who should be using unstable; and people who want to keep
more or less up-to-date, but don't want to be on the very front lines --
and these are the people the forthcoming `testing' distribution is for.

See:

	http://www.debian.org/Lists-Archives/debian-devel-9805/msg01721.html
		-- for Bdale's original statement of the above

	http://www.debian.org/~ajt/
		-- for other links to the discussion about this from just
		under two years ago, and from about a year and a half ago

	http://auric.debian.org/~ajt/
		-- for up-to-date info about the current prototype

	deb http://auric.debian.org/~ajt/ testing main
	deb-src http://auric.debian.org/~ajt/ testing main
		-- for the apt-able archive

(Terminology note: package-pools are a separate issue to the above. The
above is all about release management; package-pools are abour archive
resource management, making mirroring easier, making archives easier to
create, destroy and update, and so on. They're obviously strongly linked,
but they don't actually depend on each other. Package pools are needed to
make "unstable+testing" efficient for mirroring, and to make mirroring
much easier in general. Using "package-pools" as a term to cover all of
it makes it hard to distinguish between the two issues)

And yes, hopefully the length of freezes can be reduced, but so far we
don't have any evidence that anything we try will actually work.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

  ``We reject: kings, presidents, and voting.
                 We believe in: rough consensus and working code.''
                                      -- Dave Clark

Attachment: pgpUoLwn0kXvr.pgp
Description: PGP signature


Reply to: