On Wed, Nov 10, 1999 at 02:20:53PM -0500, Adam Di Carlo wrote:
<snip>
> > 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..
>
> No, this is wrong. I don't believe in this diagnosis. The fact is we
> want the literal freeze cycle (no new packages) to be as short as
> possible. To do that, we need to go into freeze with a functional:
>
> * base system (it's not even really functional yet, but close;
> note that some architectures don't even have their release
> kernel in place yet!)
> * boot-floppies (ditto)
> * debian-cd (not sure)
Yup..so lets try and freeze these earlier in the release cycle...
> > 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.
>
> Yet, the stability of the above items can be addressed independantly
> of the stability of all the other packages in the system. I applaud
> the release manager's decision to wait until the core shown above is
> ready before freezing.
>
> > 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_.
>
> I don't understand how the boot-floppies team is to complete and
> stabilize the boot-floppies if we're not allowed to release updates?
>
> If you're saying we should put base into freeze, then that at least
> makes some sense.
>
Ok...your right - I mean the base. In fact, if you have a read through
my other mails to this list, I've ammended the idea to include "staged
freezing", whereby the release manager moves through different sections of the
distribution - freezing them a stage at a time.
And I'm not saying there shouldn't be updates - just no new features/code. I
admit, on retrospect, that boot-floppies was probably a bad choice to pick on
(since it depends on the base, not vice-versa).
> > 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).
>
> You're just saying, or trying to say, "lets freeze base". This is
> fine but I don't think it will really fix many problems.
>
> > 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.
>
> The problem with that idea is that we don't have copies of all
> backdated versions. A better plan is simply to drop non-critical
> packages where RC bugs have not been fixed. That is what we currently
> do.
>
We can drop the packages, and ask the maintainer - who does hopefully have
older versions - to upload the old one.
> > 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.
>
> Well, I would actually try to announce to all, "please don't upload
> major new versions unless they are critical to the freshness of
> potato." So I guess I'm more of a proponent of the "common sense"
> side...
>
> Anyhow, given the fact that right now the release manager considers
> the stability of boot-floppies the delay to freezing rather than the
> RC bugs in potato, then your semi-freeze proposal doens't really do
> much to help whatever problems people think we're trying to help.
>
Your right, the idea doesn't help the problems we are having right now. This
is a proposal based on the fact that there is something wrong with our release
cycle that causes it to have these sort of problems. It is designed to help
avoid this sort of thing next time.
Perhaps another way of looking at the idea is as a way to co-ordinate the
release cycle. Instead of thinking of it like staged freezing, think of it
like staged development. If we are planning to have a four month release
cycle, then we say:
- The first 6 weeks are for major base upgrades (new libc, etc, etc)
This is the only time for those to be updated (frozen after)
- The next 3 weeks are for updates to critical applications (gcc, perl, etc)
Of course, they can be updated earlier (during the base update stage, but
they run the risk of needing to rebuild if the base changes).
- The next 2 weeks are for updates to libraries
- The next 3 weeks are for updates to everything else
- The last 2 weeks are for stabilising everything (everything is frozen).
(These time scales are just guestimates - and would be up to the release
manager, but should be decided on before we start work on a new distribution).
That way everyone has a clear idea of when things should be done to make the
4 month release cycle work smoothly. And if a new version of something is not
available in the allocated period of time (but is after) it will have to wait
until the next release cycle. This could, of course, result in a distribution
that is not very different from a preceeding one - but I don't think this is a
bad thing.
What do you think?
Chris
--
----------------------------------------------------------------------
Linux, because I'd like to *get there* today
----------------------------------------------------------------------
Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
Attachment:
pgpRFa4YOO8PG.pgp
Description: PGP signature