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

Re: Partial freeze?



I like this idea., Can we put it to a vote?

Rodney Caston


On Tue, 9 Nov 1999, Chris Leishman wrote:

> Ok,
> 
> Here is another thought (probably one that has come up before - gotta love
> going around in circles.  Let me know if I am).
> 
> The problem at the moment is that no-one wants to freeze, because we don't
> know how long we will be frozen for - and in that time things get stale and
> old.  And why don't we know how long we will be frozen for?  Because some
> "critical to release" packages (like boot-floppies) are not stable and we don't
> know how long they will take to become so.
> 
> However - IMHO if we don't freeze, then we are in the same position as
> unstable always is - at any point there can be an update that will cause a
> different "critical to release" package to fail.  Who knows - in a month when 
> we have boot-floppies working, some other new or updated package might (or 
> new policy) might still prevent us from freezing for the same reasons..
> 
> Bit of a catch 22 really.  If we freeze, then things can stabilise, but they
> might also get stale.  If we don't, then things won't get stale, but they may
> not stabilise quickly.
> 
> How about this then:  We identify those packages which are considered
> "critical to release".  This would include packages like boot-floppies and
> policy.  Then we declare a _freeze on those packages_.  The same freeze rules
> apply - only bug fixes to these packages allowed.
> 
> However, new uploads can continue while this stuff stabilises - as long as
> they don't cause problems with the "critical to release" packages.  If they
> do, then the freeze rules apply to that upload (no new code).
> 
> Eventually we freeze the whole distribution for a very short time to clean
> release critical bugs in non-core packages.  We should take a fairly hard line
> on these, and basically say that if there was a version without _new code_ 
> that didn't exhibit the problem, we backdate to it rather than bugfix.
> 
> Ok..conclusions from this idea... This _may_ lengthen the freeze time, since
> we are effectively doing 2 freezes.  But the second phase (the phase that can
> introduce stagnation) will be much shorter than it is in our current situation.
> 
> Another conclusion may be that this just sounds like common sence, and there
> is no need to make it official...but I've always found these things work much
> better when they are enforced.
> 
> The last remaining question is how workable this concept is....
> 
> 
> Best regards,
> 
> Chris
> 
> (wish me well for my macroeconomics exam in...oh...1 1/2 hours :)
> 
> -- 
> ----------------------------------------------------------------------
>             Linux, because I'd like to *get there* today
> ----------------------------------------------------------------------
> Reply with subject 'request key' for GPG public key.  KeyID 0xB4E24219
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 


Reply to: