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

Re: packages missing from sarge

On Wed, May 11, 2005 at 09:50:48AM +0200, Wouter Verhelst wrote:
> On Tue, May 10, 2005 at 11:00:48PM +0200, Adrian Bunk wrote:
> > On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote:
> > > On Tue, 10 May 2005, Adrian Bunk wrote:
> > > >How often does a quick NMU that gives a fast improvement in the RC
> > > >bugs metric hide the real problem that the maintainer is completely or
> > > >partially MIA?
> > > Actually what is your opinion how to improve the QA process?
> > 
> > It might sound strange, but I'd suggest to completely disallow NMUs 
> > without maintainer permission.
> > 
> > This would make it take longer until RC bugs are fixed, but it would 
> > help on speeding up the finding of maintainers who are for any reason 
> > not able to properly maintain their packages.
> What are we trying to do, then?
> Release Debian, or find MIA maintainers? Based on your previous mails, I
> thought you wanted the first. That will go a *lot* easier if we don't

Both belong together.

The release team plans with a < 1 month freeze and a big emphasis on the 
RC bugs metric.

To be honest, I was very surprised if the release team would miss it's 
own release date by less than one month.

E.g. there will always be problems like bugs with a too low severity or 
wrong tags that will show up late in the freeze.

If there was more focus on the many other problems like maintainers not 
properly maintaining their packages instead of only on the RC bugs 
metric both before and during the freeze, the resulting release was 
better and some negative surprises were less likely.

This might seem to defeat the goal of super-short freezes, but I have 
yet to see at least one freeze that was not only announced as 
super-short, but that was actually as short as it was announced...

> have buggy packages anymore, for which NMU's can be helpful under
> certain circumstances.

This depends on how you define "buggy packages". If you count only RC 
bugs you are correct.

But non-RC bugs aren't the only bugs. Many annoying things like 
segfaults under specific circumstances are not considered RC.

As an example, look at how many segfaults in the texinfo source package 
are unfixed for several months. And the last NMU didn't include e.g. my 
upstream-approved one-line patch for the #259561 segfault. Well, this 
bug is only "important"...

RC bugs are a metric to measure the quality of Debian. But as it is a 
well-known fact about metrics, work on improving the metric often only 
improves the metric but not what it was supposed to measure.

> If, however, you are indeed intent on finding MIA maintainers for some
> to me obscure reason, then I think it'd be nice if you'd talk to those
> people actually doing that work at this moment, to see whether they
> agree with you that NMU's make their work harder. My guess is that
> you'll find they don't, but then of course I haven't asked either.

Completely MIA maintainers are one part of the problem.

But then there's the class of maintainers who manage to upload a new 
upstream version and perhaps fix some RC bugs every few months but are 
not able to properly handle all bugs in their packages.



       "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: