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

Re: Some observations regardig the progress towards Debian 3.1



On Sat, Nov 15, 2003 at 03:42:26PM -0600, Steve Langasek wrote:
> On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> > For testing to work good, it's required to have unstable in a good
> > state. Often new so-versions of libraries enter unstable, and e.g. KDE
> > 3.2 might soon go into unstable. If testing should be frozen, it's
> > needed to _freeze unstable_ (IOW: require RM approval for every upload
> > to unstable). This doesn't need to be under a "no new upstream code"
> > policy at the beginning, but at least beta versions, new so-names and
> > major upstream releases (e.g. avoid KDE 3.2, but 3.1.5 is OK) should
> > be avoided.
> 
> Yes, I've actually been pondering whether it wouldn't make sense to try
> to serialize major transitions (such as soname changes), to improve our
> chances of keeping testing both releasable and reasonably up-to-date at
> all times.  I've also tried to encourage mini-freezes in cases where
> groups of packages were almost-but-not-quite ready for testing.

I feel we've been getting much better at this over the last few months.
The last Python transition, while a bit hair-raising, went fairly
smoothly in the end for something that affected hundreds of packages;
GNOME 2.4 looks like it should go fairly smoothly once glibc/NPTL is out
of the way; and so on.

> But based on the progress d-i has made over the past two months, it
> looks like the installer has a good chance of being ready -- even on all
> architectures -- before the rest of the archive is ready to go.  There
> have definitely been some mistakes to learn from in the time since the
> woody release, in terms of letting experimental changes loose in
> unstable;

The worst of these was sheer accident, and I think its causes have been
addressed now. Use of experimental is increasing, too.

> but sarge is definitely not standing still at this point -- even
> though the RC bug count doesn't seem to be going down,

Frankly, I don't remember the RC bug count *ever* dropping by much prior
to a release; the pattern has been that the bugs are pushed out to
packages we don't care about, which then get removed. While not perfect,
it gets the job done in finite time, it's pragmatic, and in many ways it
reflects reality.

> All things considered, we do seem to be much closer to a release now
> than we were 3 months ago.

Agreed.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Reply to: