Re: search/get bug database, rc bugs excuses, closing bugs
On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote:
> On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote:
> > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote:
> > > Where might I get a copy of the bug database? Is there any way to search
> > > the bug database by text?
> >
> > Sorry, not yet, unless you have an account on master to poke around
> > inside /org/bugs.debian.org/spool.
>
> Would all the BTS available bugs be there?
Yes, that's where the BTS stores everything.
> Would anything else be there?
Bits and pieces of state. There are no hidden bugs, if that's what you
mean.
> > > that release worthy (X.XrX+1) bugs should remain open until all the Debian
> > > distributions have the bug fixed. I think the distribution tags were
> [...]
> > They were created more as a hack for release-critical bugs than anything
> > else, IMHO. For non-RC bugs I wouldn't worry about them. The real
> > solution is proper version tracking, as ever.
>
> I said "release worthy" in case the term RC missed anything. Is there a
> draft document talking about proper verion tracking for Debian yet? Sorry
> to poke, but I'm curious. I've done quite a bit of research into BTS's,
> trouble ticket systems, contact managers, issue tracking systems... I
> haven't seen any authorative opensource solutions, just conventionally used
> programs like sourceforge (& derivatives) and bugzilla (gnats isn't really
> used much from what I've seen). I'd enjoy contributing to a Debian BTS
> rewrite.
I tend to take a very dim view of rewrites: I'd much rather extend and
improve existing code than get distracted by rewriting it, particularly
for tasks like this that require very few changes to existing code and
lots of new code. Also, when working with existing code you can
prototype the improvements alongside the live system for a while until
they become stable.
That aside, http://bugs.debian.org/~cjwatson/version-tracking.html is my
current thinking. I'm going to start prototyping the changelog parsing
Real Soon Now (I'm changing jobs in a few weeks' time, with the result
that I'll probably have a week or two in between free to hack on things
like this). At that point I'll probably know whether help is needed.
> > It's fairly simple: if a bug needs to be fixed in more than one
> > distribution then the maintainer should leave it open (possibly with
> > tags) until it has been fixed in all those distributions. Otherwise it
> > is left up to the maintainer's discretion to close it appropriately.
> > Common sense ought to apply.
>
> I agree, I just wish it said somewhere. I also wonder about
> proposed-updates? Should a bug remain open until the package makes it into
> a stable release? Perhaps the "fixed" tag should be used when a package is
> fixed in proposed-updates, but not yet in a stable release.
I'm not sure, actually. Possibly.
> Can I quote you on this issue of when to close bugs?
Sure.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: