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

Re: search/get bug database, rc bugs excuses, closing bugs



On Fri, Apr 04, 2003 at 12:18:04PM -0600, Drew Scott Daniels wrote:
> On Fri, 4 Apr 2003, Colin Watson wrote:
> > On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote:
> > > Would anything else be there?
> > 
> > Bits and pieces of state. There are no hidden bugs, if that's what you
> > mean.
> 
> Is there any structure to the file(s)? Are the sorted by
> bug/package/srcpkg? Reading another message in this thread it seems that
> each bug is in a separate file, but is there any directory structure?

Directories are hashed by the last two digits of the bug number, there
are .log, .status, and .report files for each bug, the .log format is
documented in the Debbugs::Log perl module, there are indices for
packages etc. Read the code for more.

> > 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.
> 
> Working with old code at work, and hearing the occasional groan about how
> complicated the BTS code is makes me worry about just doing a few changes.
> I am however willing to do some rewriting of debbugs.

As someone who is a relatively recent newcomer to the debbugs team, I
think that rumours of debbugs' complexity are greatly exaggerated. With
the exception of a few things I've never needed to touch, I find it
pleasingly simple and accessible, and I've had no problems doing the
things I needed to do.

> > 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.
> 
> Very interesting. I'd like to comment on this and say that I think that
> perhaps branches should be tracked according to the distribution
> directories.
> 
> Changes in the woody branch may not (or can't?) appear in the changelog for
> the unstable branch of a package.

Then the bugs should be closed by the changelog in the unstable branch
as well. Maintenance-wise that's the best approach too.

> I think the tags potato, woody, sarge and sid could all be extended.

No, I think they should die. They're too crude, only a few people
understand exactly what effects they have, they're a hack because tags
were the only mechanism available at the time, and version tracking
should render them entirely obsolete (much like the way the old fixed
severity is now disabled). We should have extra status fields for the
purpose instead.

aj's proposal for extra control messages is here:

  http://lists.debian.org/debian-debbugs-0210/msg00033.html

(there's more discussion in the following month's archives)

> And another nice feature to have would be to allow viewing of bugs by
> distribution.

Yes, that's an inherent part of version tracking.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Reply to: