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
maintain.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature