On Sun, Nov 16, 2003 at 12:34:27AM +0000, Colin Watson wrote:
> 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.
glibc/NPTL is an example of a nice new feature that breaks other
packages (e.g. it causes mail loss for some people using the cyrus-imapd
package from testing or unstable).
NPTL is _really_ nice, but these are the changes that wouldn't occur
after the beginning of a freeze.
>...
> > 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.
>...
Why is this better than starting a freeze and fixing the bugs in bug
squashing parties?
The problem with your pragmatic approach is that every of your users has
other packages he cares about. A package you care zero about might be
the killer application for some users.
This might not be a problem if it happens for one package, but if it
happens for e.g. 500 packages the sum of people affected by at least one
of these removals will be quite large.
If someone wants to answer "But noone cared enough to fix this package!"
now, he forgets that there is a distinction between developers and users
of Debian.
> Cheers,
> Colin Watson [EMAIL PROTECTED]
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
