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

Re: Which release-critical bugreports are really release-critical?



* Colin Watson (cjwatson@debian.org) [031222 12:25]:
> On Mon, Dec 22, 2003 at 10:36:06AM +0100, Andreas Barth wrote:
> > * Steve Langasek (vorlon@netexpress.net) [031222 04:40]:
> > > On Sun, Dec 21, 2003 at 10:14:19PM +0100, Andreas Barth wrote:
> > > > I've asked myself this question for more than one time. So I played a
> > > > bit with perl today, and generated a statistics of the RC-bug reports
> > > > that match the following conditions:
> > > > - Package is actually in Sarge
> > > > - Bug is (tagged Sid | has no release tag at all)
> > > > - Bug is neither fixed nor sarge-ignore
> > > 
> > > > With these conditions, I count about 368 bugs right now.
> > 
> > > Does this account for packages which are in sarge, but are specific to
> > > a particular architecture?

> > You mean the "Package is actually in Sarge"? I checked it that way
> > that the bugs are not preceded by [X] on the official RC-bug count.

> The implementation of that [X] thing is ... a little stupid. There may
> well be more bugs that only exist in the version in sid.

Well, perhaps I asked the wrong question. I asked for the bugs of
packages that are in Sarge, but where is no solution up to now at
least in Sid. Of course, there are some bugs solved by packages that
are in Sid, but not in Sarge (and some of these RC-bugs are just
closed at upload). But for my purpose ("where would it be usefull to
put some effort in to get nearer a release") these bugs can be ignored
in the first run.

Of course, this assumptation would be wrong for e.g. the release
manager to decide to actually release sarge based on this data. And it
would of course also wrong if looking where e.g. some hinting would be
appropriate.

I for myself would try to look at these question with the question:
Which packages are actually in Sarge, but have a newer version in Sid?
Ideally, at release time there should be no such package.
(And one could ask the sub-question with ignoring all too young
packages, as they don't usually need effort.)


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C



Reply to: