Re: Staged Freezes
On Sat, 13 Nov 1999, Chris Leishman wrote:
> On Fri, Nov 12, 1999 at 06:40:18PM -0500, Adam Di Carlo wrote:
> >
> > I don't think it can be done the way your suggesting it. However, if
> > we were on a package pool kinda plan, where developers always upload
> > to unstable and some sort of release team who pull packages down into
> > a release candidate distro, then it might be a good idea.
> >
Let me prefix this by saying I would have said this had Adam not done so.
> As for the package pool - the problem I see here is that it puts alot of
> strain onto the release team - they have to work out which packages they can
> pull down (and which versions, to maintain stability).
I'd propose 2 things, the developer says they want their package
considered for the current proposed dist, and second, the transfer from
the pool to the proposed is done using the bug tracking system and a
delay. The delay is to give time for old bugs to be closed and new bugs
to be opened, say a week. Given no open bugs and a developer desiring to
move the package to proposed, then do it automatically.
> Also, if everyone is uploading to unstable, then release stability is going to
> be difficult to achieve since no developers needs to have total stability as
> a primary goal. Sure, they will have their packages internally stable - but
> since they don't know what other code bases its going to be working with, they
> can't work towards stability in terms of interoperation with the rest of the
> distribution (eg they don't really know which libraries, etc, etc will be in
> the final release).
People still download what they want, actually there would then be 3
instead of 2 levels, stable, proposed, and pool. Any bugs in proposed are
quickly backed out of. The pool is the developer and tester area. The
proposed is another tester and update-happy user area. Leaving stable
where it always was, boring and proven, the way it should be.
> The other problem is that you are no longer goal setting for the large body of
> developers. There is no "we want to freeze in 1 week - lets get everything
> done people". IMHO a project like this really relies on goal setting to keep
> developers interested and active.
Goal setting results in longer freezes and periods between freezes.
Playing catch-up and the desire to see something cool motivates most
people. Goals can still occur, they just can't hold everything up.
Across the board changes can still occur, they just move to a different
proposed area.
> If my opinion means anything, we should steer well away from the idea of
> developers only working on a perpetual "unstable" distribution...
I'm not discouraging your ideas, just putting more out so that the best
one wins. I put this one to rest around the time that Richard came on, in
hopes that he could fix things, but, not to blame him (it's the system
man), things seem to be the same.
Thoughts,
Brandon
Brandon Mitchell * http://public.surfree.com/bmitch
bmitch@surfree.com * ICQ: 30631197
Reply to: