Re: Partial freeze?
I suggested something similar several months ago, where we get "Base" completely
solid. Then go on from there, in order of importance. Obviously, libc should
NOT be allowed to change at this point. Yes, there may be newer versions, but
if it's not causing problems, let's not worry about it. I have been an active
Debian user since 1.3.1(a relative newbie compared to many of you), and have
seen that the dependancies are not used to decide when to update packages.
While I applaud the efforts of all the developers, building a package 10 times
over the development cycle because of glibc updates, and other updates seems
like it's a lot more work than should be required. If the FIRST thing to be
updated is the base packages, then it will make life a LOT easier for the rest
of the developers. This wouldn't solve the problem, but would reduce the number
of package builds.
Dave Bristel
On Tue, 9 Nov 1999, Chris Leishman wrote:
> Date: Tue, 9 Nov 1999 07:23:23 +1100
> From: Chris Leishman <masklin@debian.org>
> To: debian-devel@lists.debian.org
> Subject: Partial freeze?
> Resent-Date: 8 Nov 1999 20:23:33 -0000
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipient list not shown: ;
>
> 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: