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 [EMAIL PROTECTED]
