I sent this a few days ago on the Releases thread to -private and, as
this is now being moved to -devel, I thought I might as well forward it
here as well..
Zephaniah E. Hull
--- Forwarded message from "Zephaniah E. Hull" <warp@whitestar.soark.net> ---
Date: Sun, 7 Mar 1999 17:06:10 -0500
From: "Zephaniah E. Hull" <warp@whitestar.soark.net>
To: debian-private@lists.debian.org
Subject: Re: Releases
Mail-Followup-To: debian-private@lists.debian.org
X-Mailer: Mutt 0.95.3i
(Note that I just got back from vacation, and am still /VERY/ behind on
my mail..)
On Fri, Mar 05, 1999 at 08:43:46PM +0000, Adrian Bridgett wrote:
> On Thu, Mar 04, 1999 at 07:55:32PM +1100, Craig Sanders wrote:
> [small amount of snippage <g>]
> > new/holding -> unstable -> frozen -> stable/release
>
> I like this (and of course Incoming beforehand). I like to be up-to-date,
> but not bleeding edge - I would use unstable.
Hrm, I'd venture something like
broken |-> unstable -> slush -> solid -> release
(See below)
>
> Programs moved from Incoming would go into new/holding where the people who
> hit them can find the nasty bugs to prevent them reaching the wider world.
> Checking the bug list before submitting a bug on new/holding would be
> encouraged more than ever - we really don't need serious bugs reporting
> thirteen times.
I'd like to see the maintainer decide if a package goes to broken (or
whatever) or unstable..
Broken would be named such to really make people think thrice before
using it, it would be used for packages which are very likely to be
broken, or there is a very high risk of a mangled system if a bug would
appear.. (IE, X, libc, etc)
(I have two ideas on promotion for this, see below)
Unstable would play mostly the role it does now, except that hopefully
wide breaking changes would go to broken first..
>
> I'd suggest 2 days for most packages from new/holding to unstable. Of course
> large changes (like X-windows) could stay for much longer so they can be
> tested (without remembering wierd directories on master....)
For a rapid test->break->fix->upload->test->... cycle it should be up to
the maintainer, two days may be a killer for this, on a minor package
with changes which have no chance of doing major damage, on the other
hand, for libc for instance, two days could be FATAL to a large number
of systems, far too short..
(And I don't see how to signal to hold it nicely? Hrm)
>
> I really like the idea of auto-promotion - we will end up with a more
> reliable distribution, faster, with more up-to-date packages in it.
Yes, but with it one must be-able to control auto-promotion, so I propose
the following:
The BTS would be modified to keep track of bugs on packages based on the
dist (broken, unstable, slush, solid, release, or such)..
This could be done in several ways:
1: A new field on each bug report which lists each dist affected.
2: Bugs would be against <package>-<dist>, or some minor variation.
(ICK!)
3: Some other nice, clean, answer, which someone else has in their head.
Then auto-promotion could work something like:
(template, I'm not going to copy it around for all the dists yet, if
its wanted I can do it, and will before this could become some official
policy proposal)
-start-
If the package version has been in <cur-dist> for <time>, and no bugs
exist with a severity of important or higher for this package in
<cur-dist>, the package is promoted to <next-dist>.
-end-
Broken: This one has two options I see..
1: No auto-promotion, the maintainer makes a new upload.
2:
If no bugs exist with a severity of important or higher for this package
in broken, the package is promoted to unstable.
(A bug of severity important should probably be submitted automaticly on
upload to broken if no such bug exists, requiring the maintainer to
close it for it to be upgraded)
Unstable:
Template with:
cur-dist = unstable
next-dist = slush
time = 1 week
Slush:
Template with:
cur-dist = slush
next-dist = frozen
time = 2 weeks
Frozen:
Probably not run automaticly, and all packages are moved at once, no
packages are promoted alone, with the following rough guidelines.
When all package versions in frozen have been there for three weeks, and
no bugs exist with a severity of important or higher for any packages in
frozen, then frozen may be copied as a whole to release.
(Of course, the release manager can override this for specific packages)
Now, the times above will definitely need some work, and the guidelines
probably need some as well..
>
> I feel that we penalize stable packages too much - a two month freeze may be
> appropriate for some packages, but others just get out of date (and with
> fewer bug fixes).
We have a choice, completely, bleeding edge, hopefully stable, releases.
(See Red Hat 5.1)
Or a little out of date, but rock solid stable releases..
A lot of our users use us because we choose the 2nd, and for my critical
servers I'm one of those...
Zephaniah E. Hull..
(You may move this to -devel if you wish..)
Ob-Private: Move this to -devel and/or -policy after Slink release..
>
> Cheers
>
> Adrian
>
> email: adrian.bridgett@zetnet.co.uk, http://www.poboxes.com/adrian.bridgett
> Windows NT - Unix in beta-testing. PGP key available on public key servers
> Avoid tiresome goat sacrifices -=- use Debian Linux http://www.debian.org
>
>
> --
> Please respect the privacy of this mailing list.
>
> To UNSUBSCRIBE, email to debian-private-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
PGP EA5198D1-Zephaniah E. Hull <warp@whitestar.soark.net>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
CCs of replies from mailing lists are encouraged.
----- End forwarded message -----
--
PGP EA5198D1-Zephaniah E. Hull <warp@whitestar.soark.net>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
CCs of replies from mailing lists are encouraged.
Attachment:
pgpJ2Mo3XNCZW.pgp
Description: PGP signature