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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
