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

Re: Debbugs reimplementation

Daniel Ruoso wrote:
> The only reason for considering a rewrite was the fact that when I
> opened the source code of debbugs to see what would be necessary to
> include bugs dependencies I saw that the code is absolutely non-modular
> and I actually couldn't find the way to do the proposed change, I mean,
> the problem is the maintainability (does this word actually exists in
> english?) of the code.
> I was thinking about an object-oriented re-implementation, using some
> relational database (probably mysql) to make it easier to change the
> behaviour of the system later.

I smell a second system disease.. FWIW everyone who has suggested doing
this to debbugs before has wandered off and gotten lost in a SQL schema
and never came back.

I have never looked at debbug's code before, although I once created
something to convert some data into the internal format it uses for
storing bug logs (which is avsolutely the ugliest data format I've ever
seen except a restaurant inventory control system I once reverse
engineered). However, I know that you should start with the data when
making any modification of this sort to a program (I outlined the basic
new data that would be needed in my bug report 3 years ago).

5 minutes of grepping to see how debbugs stores the data for tags and
backtracking that to the module that reads and writes them from the
database landed me in Debbugs/DBase.pm, which has a ParseVersion1Record
and a WriteRecord subroutine which both deal with the fields of a bug.
The code is fairly clear, these write to the *.status files in eg
merkel:/org/bugs.debian.org/spool/db-h/99; the files are just a list of
lines and new data can easily be added.

A simple, untested patch:

--- old/debbugs-2.4.1/Debbugs/DBase.pm  2000-06-18 01:03:23.000000000 -0400
+++ debbugs-2.4.1/Debbugs/DBase.pm      2005-03-15 15:38:19.000000000 -0500
@@ -44,7 +44,8 @@
     my @data = @_;
     my @fields = ( "originator", "date", "subject", "msgid", "package",
-               "keywords", "done", "forwarded", "mergedwith", "severity" );
+               "keywords", "done", "forwarded", "mergedwith", "severity",
+               "dependencies" );
     my $i = 0;
     my $tag;
     my (%record, %btags);
@@ -129,7 +130,8 @@
     my ($recordnum, %record) = @_;
     my @fields = ( "originator", "date", "subject", "msgid", "package",
-               "keywords", "done", "forwarded", "mergedwith", "severity" );
+               "keywords", "done", "forwarded", "mergedwith", "severity",
+               "dependencies" );
     #Open Status File
     print "V: Writing status $recordnum\n" if $Globals{ 'verbose' };

Now if you look for "tags", you'll also find it in ./scripts/service.in.
This is a bit of a mess, but it's the code that manages the control@ mail
interface apparently. There's a huge if/else statement which one would just
add a clause to for matching commands of the form "dependencies nnnn nnnn" or
whatever; the code that does the same thing for the "tags" command would
be a good template. It would come down to something like this:

elsif (/$matches_dependencies/) {
	$data->{dependencies} = extract_dependencies($_);

After getting that working, the BTS would accept control mails that
add dependency information to bugs, and storing them in its database, and
it's only a matter of using this data in interesting ways. Maybe we'd want
to start with displaying the dependencies on the web page for a bug. We
all know the name of this script in debugs, it's cgi/bugreport.cgi. In here
I'd expect $status->{dependencies} to work after the above changes,
and it's a simple matter of pretty-printing the data.

That concludes my first 15 minutes with the debbugs code. It's not the
prettyiest code I've seen, but it does not look particularly hard to

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: