Re: Bugzilla'd version of our gnats database

[Daniel Berlin <dan at cgsoftware dot com>]

On Wed, 19 Dec 2001, Joseph S. Myers wrote:

> On Wed, 19 Dec 2001, Daniel Berlin wrote:
>
> > > Will this MIME-decoding handle both gnatsweb attachments, and MIME in
> > > follow-up messages included in the audit trails?
> >
> > Errr, sure, if you want me to do that, that's fine.
>
> I think decoding both is desirable.  Gnatsweb attachments, obviously - but
> also, when people have sent the testcase for a bug as a followup to the PR
> when told a testcase is needed, such testcases have often been MIME
> encoded (whether in the message body, or attachments).  Probably
> attachments to followup messages should become attached to the bug report
> ("created an attachment", or however it appears in Bugzilla audit trails);
> the message text and inline parts probably go in the bug report audit
> trail, but probably should be downloadable separately as well.  (This also
> applies to multi-line fields in the PRs: they should be downloadable, as
> well as appearing in the bug report body, since they may contain patches
> that aren't suitable to cut and paste.  Does Bugzilla make it easy to
> download field contents this way?)
Okay, i'm on it.
Yes, bugzilla makes downloading field contents easy.
In fact, you can mark attachments as patches, too.
>
> > Bugzilla can handle it's own input format.
> > This is an XML format (with a dtd that defines it) for
> > importing bugs.  This is actually how things like gnome's bug reporter
> > work, and is also useful for moving bugs from one bugzilla to another.
> >
> > Besides this, they have have mail handler with a more human format, kinda
> > like gnats.
> > I could easily hack this script up to convert gccbug format
> > to bugzilla instead.
>
> I think we want people to edit a human format, in a text editor, called by
> a gccbug script.  If convenient we could always create a new gccbug script
> that uses a new format rather than the existing one - for example, this
> might lend additional structure to bug reports, or use a helper executable
> to attach files in a compressed form.  But we'll still need to accept and
> convert PRs from the existing gccbug script, and remap the subject line of
> follow-ups to existing PRs sent to gcc-gnats, before sending them on to
> Bugzilla, so that they get filed properly.

Yup.

>
> > > Can you make explicit fields in the bug reports for the host, build,
> > > target, configure arguments information that gccbug inserts in bug
> > > reports?
> > Sure, i can add the fields to bugzilla if you like, or throw them in the
> > initial description, whatever you prefer.
>
> These should be fields.  In principle I'd like some way for automatically
> verifiable testcases to be included, but that can be done later.
> (Presuming that you can easily add new fields, defaulting to empty, to a
> Bugzilla while it's running.)

Okeydokey.

>
> Do you have a summary of how the existing GNATS fields currently map to
> Bugzilla ones?
Yes.
For the most part, it's a straight translation.
Organization gets dropped.
I throw the description + how-to-repeat in the "description"
Each state change gets put as an additional comment with the right time
and commenter, with the state-changed-why as the comment, as well as the
state-changed-from-to.

etc.
Attachments i'm putting the finishing touches on.

While it's trivial to handle the attachments in real incoming mail input,
because the gnats reports have multiple email messages in them, i have to extract
the emails, then decode them, then insert the attachments into the
database.

> (Some of the existing ones are useless, and should not be
> collected for new PRs, and can probably be removed in the conversion -
> Submitter-Id (always "net"),
Right.
> Organization, and probably Severity (since we
> use only Priority for release management, and user estimations of
> importance of their own PRs are rather useless).

Priorities currently map to the default priorities of P1-P5.
A combination of class and severity map to severity.

The severities in bugzilla can be changed to whatever list you want, as
can the priorities.


> Priority should map in
> some way to milestones - and shouldn't be able to be set by users
> submitting PRs, only by those with write access.)

Priority can be be made unmodifiable by submitter and defaulted to
something on submit.

You can target bugs to certain milestones if you like already, and you
since you can have it change multiple bugs at once, to mark all the
bugs of a certain priority as targeting a certain milestone, you could
just do a query, then tell it to change them all (it's on the query
result screen).

You can also require a milestone to be assigned when someone accepts a
bug, if you like.

I can tailor it to whatever requirements we have *after* i've got the
import perfected.

I would have it all done by now, except it's exam week, and i've got an
exam tomorrow.


 > --
> Joseph S. Myers
> jsm28@cam.ac.uk
>