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

Re: Skipping the slink freeze and work on Debian 2.2 instead



[ I think Guy Maor will read this in debian-devel, but I'm not sure about
  Brian White, so I'm trimming the Cc: list partially ].

On Fri, 30 Oct 1998, Martin Schulze wrote:

> It will take quite a while to fix and test all these packages before
> we can release slink.  Therefore we should consider to skip the slink
> release or make the darn freeze *now* and work on fixing these
> packages without introducing more instabilities.

[ Note: I don't fully understand what you did you mean with "skipping
  slink release". By definition, slink will be the next stable release,
  will we release it in late November or in January 1999 ].

I agree that announcing a freeze and not freezing is not a good thing, but
freezing something in such a bad state would not be good either.

IMHO, the gap between the freeze and the release should be small.
We should freeze when unstable is "stable" enough. The remaining time
until the release should be spent in testing, not in fixing more bugs and
doing yet more uploads (we should of course do that too).

For this reason I would propose the release manager to decide his freeze
dates based on short-term not-too-difficult-to-achieve goals, and *not* on
fixed dates decided beforehand.

For example, some of those short-term goals could be:

* That 100% of all Priority: standard or higher packages which need to
be recompiled against libncurses4 are already recompiled.

* That 100% of all Priority: standard or higher packages which need to be
recompiled against slang1 are already recompiled.

We could decide the freeze date exactly as the one this is achieved.
[ Of course, severity: important bugs should be submitted for this ].

We could then spent some more time during the freeze to recompile
all the other optional packages.

Only this way we will make sure that slink will be "mostly"
libncurses4-based and slang1-based.

If we freeze now without having achieved those short term goals, the
freeze will take much more time, and it is likely that we will be forced
to release anyway "because the freeze has been in place too many time".
I don't think we should do that.


In either case, I would advocate for some sort of "release manual".
The freeze date should be decided according to some *objective* rule,
whatever it will be (my idea of short-term goals is just an example), not
according to the wishes of a single person.


[ Just my 0.02 euros ].

-- 
 "b9ebbf1059ede42479b6c408fccb2446" (a truly random sig)


Reply to: