This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bugzilla'd version of our gnats database
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Daniel Berlin <dan at cgsoftware dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Wed, 19 Dec 2001 12:03:16 +0000 (GMT)
- Subject: Re: Bugzilla'd version of our gnats database
On Wed, 19 Dec 2001, Daniel Berlin wrote:
> Until I finish making it mime-decode the embedded attachments and throw
> them in the attachment database, i've cut out the actual bug
> *descriptions*. I'll also make it parse audit trails into bug history.
Will this MIME-decoding handle both gnatsweb attachments, and MIME in
follow-up messages included in the audit trails?
Of course, some converter will need to sit on the gcc-gnats address,
handling both follow-ups to GNATS PRs and gccbug submissions (and sending
anything that can't be interpreted to a moderator, who will inject them
manually if they aren't spam). There maybe should be a new version of
gccbug adapted better to Bugzilla, though we could just have the converter
handling GNATS-style gccbug input forever.
Have you got a working configuration for mail to/from Bugzilla, as
discussed in the previous discussions of this topic? (All bugs and
follow-ups sent to mailing lists, including attachments, with a Bugzilla
address in the headers such that follow-ups also go to Bugzilla and get
filed and sent on to gcc-prs.)
Can you make explicit fields in the bug reports for the host, build,
target, configure arguments information that gccbug inserts in bug
reports? (In addition to preserving the full text of the "Environment"
field, since people may have inserted other random information there.)
> I changed it to search for specific releases (2.95, 2.95.2, 2.95.3, 3.0,
> 3.0.1, 3.0.2, 3.0.3) in the Release: line it was parsing. I also added a
> generic extractor for the "x.x YYYYMMDD (experimental)" format that was in
> there at times. Everything else was tagged as unknown.
>
> This seems to work fine, it gave us a nice list of versions (147).
> It would probably make sense to just label all of the
> experimental YYYYMMDD's of version x.x as version "x.x pre", which i'll
> do in the script.
The full version also needs to be visible somewhere in the bug report -
though for a basic search, the main version number (and a date range for
prerelease/experimental versions - e.g. 3.1 200112) is enough, the full
version with date is important information (which I made gccbug report
since when it just said "2.97", that was very little information about
what GCC was really being used).
--
Joseph S. Myers
jsm28@cam.ac.uk