Re: Bugzilla'd version of our gnats database

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

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?)

> 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.

> > 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.)

Do you have a summary of how the existing GNATS fields currently map to 
Bugzilla ones?  (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"), Organization, and probably Severity (since we 
use only Priority for release management, and user estimations of 
importance of their own PRs are rather useless).  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.)

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