Hello all,
Wichert has pointed me to this list to discuss the staged freezes proposal.
I am newly subscribed to this list - so please excuse any lack of knowlege,
etc...(I'll try and go through the archives when I get a break from work).
I have included below my original proposal, and a good amendment (to do with
Staging, rather than partial freezing) below that.
I think comments on the workability of this idea would be good - particularily
from those responsible for releases and the dinstall process...(I don't know
that much about it).
Regards,
Chris
----- Forwarded message from Chris Leishman <masklin@debian.org> -----
Date: Tue, 9 Nov 1999 07:23:23 +1100
From: Chris Leishman <masklin@debian.org>
To: debian-devel@lists.debian.org
Subject: Partial freeze?
X-Mailer: Mutt 0.95.6i
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 :)
----- End forwarded message -----
----- Forwarded message from "James A. Treacy" <treacy@debian.org> -----
Date: Mon, 8 Nov 1999 17:26:56 -0500
From: "James A. Treacy" <treacy@debian.org>
To: Chris Leishman <masklin@debian.org>
Cc: debian-devel@lists.debian.org
Subject: Staged Freezes [was Re: Partial freeze?]
X-Mailing-List: <debian-devel@lists.debian.org> archive/latest/48985
On Tue, Nov 09, 1999 at 07:23:23AM +1100, Chris Leishman wrote:
>
> 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.
>
I believe staged freezes is a better name for this and it shouldn't be
restricted to only 2.
A good way of partitioning the packages is as follows:
1) everything in base and the boot-floppies
2) critical apps (for example gcc, X and the parts of perl not in base) plus
libraries which only depend on base
3) libraries which depend on other libraries
4) everything else
Partitioning the packages could be automated, with a list of exceptions to
take care of things like X. Even complicated systems like gnome fits into this
partitioning quite well.
If we wanted a 4 month release cycle, stage 1 would freeze 6 weeks after the
previous release and each succeeding stage after an additional 2 weeks. This
would leave a 2 week freeze for stage four followed by a final 2 weeks of
testing.
What this does is to remove the current rush of everything happening at once.
Those parts more critical to the release, and needing more testing, get more
time, while allowing less critical parts to be more current. It also minimizes
changes that would break packages that are already frozen. For the most part,
changes should only cause problems with packages that haven't been frozen yet.
Some people may want to collapse 3 and 4 into one freeze. While this is
possible, it can only be done if complicates systems, like gnome, are managed
carefully (it was gnome that made me decide to split them).
--
James (Jay) Treacy
treacy@debian.org
----- End forwarded message -----
--
----------------------------------------------------------------------
Linux, because I'd like to *get there* today
----------------------------------------------------------------------
Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
Attachment:
pgpRvGcIY6rRA.pgp
Description: PGP signature