Re: slink is gone, goals for potato?
On Wed, 3 Mar 1999, Craig Sanders wrote:
> yeah, i figured that. just thought it needed to be said BEFORE someone
> else said something saying like 'hurting unstable is an acceptable price
> for speeding up frozen'.
I was keeping my thoughts on "acceptable" out of the matter on purpose :-)
> as has been discussed many times before, it is NOT an acceptable price.
> it will do debian no good at all to destroy the enthusiasm of productive
> developers who have nothing to work on for frozen but are prevented from
> working on unstable.
I sometimes think there are ways to do this right without hurting debian
as a while (not unstable). Think of the linux kernel. I realize it's a
completely different model, but people are still enthusiastic to
contribute. Unfortunately, I can't think of how this one program model
can really apply to our thousands of programs model.
> "what interests us" and "what we are capable of" may or may not have any
> resemblance to what is needed for the freeze or release.
My fear is that the developers interests and needs are diverging from
debian's needs for releasing a product. We are gaining developers that
want to work on new packages faster than developers that want to help with
another release.
> This is why i think that releases should be handled by a volunteer
> Release Team who pick the best stuff from unstable and turn it into a
> release...the freeze -> stable release cycle should be independant of
> the live "unstable" debian.
Ok, if you are talking about the change in stable, frozen, and unstable to
a different method all together with a holding area, then I've heard that
one. I've just learned not to suggest radical changes like this because
they never seem to get implemented even if a majority agrees. I
personally don't agree with the team approach. A more automated method
that moves packages from a holding area to a pre-release area using a no
major bugs and a few days condition would work. This could all be
automated so that you just add "holding" to the distribution list. Bugs
can be automatically checked as well as the number of days. After a few
months, pre-release is locked up tight with updates done by hand. After 3
weeks and all bugs (if any) are closed, then it's released. This means
unstable never becomes stable, something that could really reduce the
release time. I'm pretty sure all this has been said before. The
automated approach just means someone has to "show the code" and everyone
has to agree.
> > Any better pointers? I'd like to see this thread because I know we've
> > been trough it before, but a search for Bdale in devel over the last 6
> > months was empty.
>
> i'll try to dig up a reference. if i find one, i'll email it to you
> later today. i know that bdale first suggested it during the hamm
> freeze. several other people came up with similar proposals about 2
> months into the slink freeze.
Ok. If you don't find it, no biggie, I think I remember which one you are
refering to.
Thanks,
Brandon
+--- ---+
| Brandon Mitchell bmitch@atdot.org http://bmitch.dhis.org/ ICQ 30631197 |
| Throughout history, UNIX systems have regulary been broken into, beaten, |
| brutalized, corrupted, commandeered, compromised, and illegally fscked. |
| -- UNIX System Administration Handbook |
Reply to: