Re: testing and no release schedule
On Fri, Apr 02, 2004 at 11:34:11PM +1000, Anthony Towns wrote:
> On Fri, Apr 02, 2004 at 12:49:55PM +0200, Adrian Bunk wrote:
> > > There are two main reasons for that: one is it's essentially impossible
> > > to install testing, although we might see that one solved after sarge
> > > is released with d-i. The other is that there's no security support
> > > for testing, and there's still no prospect of that changing.
> > The first issue you mention isn't an issue for people who upgrade from
> > the current stable.
>
> *shrug* People can't upgrade from current stable and use testing because
> there's no security support, and people can't install testing from scratch
> because there's neither an installer nor security support. That takes
> away pretty much all of the motivation for worrying about other details
> that stop it from being "constantly releasable"; which leaves only its
> other use, namely "helping prepare the next stable release". You're
> welcome to dispute the utility of it there, but I can assure you that
> in my experience it's both a far more efficient use of my time and has
> far better results than the alternatives.
>...
> > I
> > personally know a person who had serious mail loss because of #220983,
> > and the cyrus-imapd/libc6 combination causing this problem was in
> > testing at this time.
>
> I've no idea why you'd want to worry about occassional mail loss when
> occassional remote root exploits are still a problem.
Forgive that I'm no native speaker.
I tried to say the following:
Even if the two issues you mentioned (no security upgrades for testing
and no installer for testing) were resolved, a bug like #220983 could
still happen every day in testing.
>...
> > There were also two months spent in three test cycles. During the first
> > two test cycles several bugs were discover that were fixed before
> > Debian 2.2.
>
> Several bugs? Hundreds of RC bugs were discovered and fixed in that period.
I fully agree with you.
In potato, hundreds of RC bugs were discovered and fixed during test
cycles that were several months after the actual freeze.
But according to the current release plan for Debian 3.1, Debian 3.1
might be released a few days after the actual freeze.
How do these two things fit together?
> > This wasn't "bug fixing", it was "bug finding", and the thorough
> > testing contributed to the good quality of potato.
>
> Yes, and that's what's going on now. That's what the installation-reports
> and upgrade-reports pseudo packages are for. That's what the
> debian-testing list is for. That's why people run pbuilder. It's why
> people run unstable and testing systems, even without security support.
>
> If testing is important -- and it is -- it needs to be done continually,
> not for a few weeks or months just before release.
But you are testing a moving target.
E.g. if an upgrade works today it might no longer work tomorrow.
> > I'm wondering why the Debian 3.1 schedule is so tightly coupled on _one_
> > external source (the Debian installer), but lets nearly no time for
> > testing after actual freeze.
>
> You shouldn't be. The reason Debian's so tightly coupled to one particular
> project (which isn't remotely external), is that of the software required
> for a stable release, it's the only one that's not within a few days or
> a fortnight of ready to be released.
>
> The reason we don't set aside much time for "bug fix only" work
> immediately before a release is that we don't have the resources to
> manage it per se -- we have some 20k open bugs across some 5000 packages,
> and manually verifying that uploads of those packages aren't accidently
> adding features simply isn't possible -- and the nearest compromise we
> have -- which is limiting it to RC bugfixes only -- simply doesn't need
> a long freeze the way we're doing things now.
I heavily doubt this statement was true.
> > The many package removals are not something I'm a fan of.
> > During the potato freeze, it was always clear which package might be
> > removed long before.
>
> Every package on http://bugs.debian.org/release-critical is a candidate
> for removal. A list of such packages is posted to debian-devel-announce
> regularly. I don't believe any of those packages are being removed within
> a few weeks' of an RC bug being filed unless the maintainer specifically
> asks otherwise; if that's not the case, it's probably a mistake and I'd
> be interested to see any examples.
Today, update_excuses says
* -sleuthkit (1.61-4 to -)
+ Removal request by cjwatson
+ Package is broken, will try to remove
I see exactly 0 open RC bugs against sleuthkit.
> > I'm not concerned about "very important" packages like Gimp. I'm more
> > concerned about one package here and one package there like users are
> > asking "Why is gnuchess not in Debian 3.0?".
>
> I can't say I'm particularly impressed at not being able to find an
> explicit answer to that; but the simplest explanation is that Bug#102449
> didn't get fixed for ten months (two months as RC), and the fix didn't
> get uploaded to unstable in time before the "zero kelvin" freeze began.
> I can't see an obvious reason why the fix didn't get in, though there
> were two security holes discovered later (Bug#162701 and Bug#163757),
> and there was a relatively severe usability bug discovered within a week
> or so of the "fixed" version's upload, that didn't get fixed for five
> and a half months. I don't think I knew about either of the first two
> bugs, and don't see why I would've considered the other bug RC, though;
> it's possible the lack of gnuchess was accidental.
>...
How are such accidents avoided today?
> > I have sometimes the
> > impression removing packages should in some way punish the maintainer.
>
> It's not about punishing anyone; it's about making sure that everyone
> else who uses Debian actually ends up getting a result.
NMUs and dropping packages from testing seems to be quite common. Why
dropping MIA maintainers (which would be more effective in the long
term) less common?
> > > If you think this is a major problem work on ensuring programs with bugs
> > > are found and fixed in unstable, or beforehand.
> > This doesn't reduce the continous stream of new bugs and problems
> > introduced by new upstream versions. And it often takes a month or two
> > until some serious bug is discovered and reported.
>
> Huh? "Finding and fixing bugs before they get into unstable" "doesn't reduce
> the new bugs by new upstream versions" ?
>
> If you really think that, you've either misread or misunderstood what
> I said. Let me translate: find and fix the bugs in upstream or unstable
> before they get to testing, let alone stable.
>
> Do it before the package gets out of development versions. Do it
> by writing automated test suites, or packaging the software for
> experimental. Or do it some other way. Whatever.
"Finding and fixing bugs before they get into unstable" is very
optimistic. Consider e.g. how well-tested new libc6 uploads usually are,
and a bug like my example #220983 above was present in testing.
> Cheers,
> aj
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
Reply to: