Re: Bugzilla features

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

On 19 Nov 2001, Matthew P. Barnson wrote:

> 2. Handles MIME in mail.
> 
>   You mean MIME attachments?  Yep, Bugzilla does it, but it doesn't
> currently read MIME type really well.  If it's text, it shows up as
> text, but anything that's binary is simply binary (Microsoft Word .doc
> files and such) if downloaded from the web interface.  Also the binary
> attachment will NOT be forwarded to the mailing list -- only the body
> text will go as a comment.

The main point is that, when someone sends a follow-up by mail, and that 
is QP-encoded (say), it appears cleanly in the bug logs (rather than, as 
at present with GNATS, as raw quoted-printable).  I've explained in my 
other reply
http://gcc.gnu.org/ml/gcc-bugs/2001-11/msg00606.html
that we *do* want attachments to go out in mail.

> 5. Follow-ups sent to gcc-gnats for existing PRs get filed properly in
> any new system.
>   Hmm, mirroring a mailing list to the bugmail system?  That would be
> problematical, but could be done with the right procmail filters in
> place.  It's easier to say that followups to
> "bugzilla-daemon@wherever.org" would go to bugmail, but not replies to
> the mailing list.  Bugzilla's not a mailing list archive system, really.

gcc-gnats is the current address for submissions to GNATS, not a mailing
list - so, for replies for existing bug reports converted into Bugzilla,
we'd need a converter sitting there that sends replies onto
bugzilla-daemon.  New messages sent out about bugs to people and the lists
can include bugzilla-daemon somewhere in their header addresses so that
replies will go there and get properly filed.

> difference with it and gnats... Bugzilla, by default, is not an "open
> bug receiver".  I have a patch to enable automatic bug creation upon
> emailed bug submission, but I can tell you from experience that this is
> an open door for Spammers to get a large target audience.  

Experience shows this not to be a problem with the GNATS setup.  When spam
goes to the gcc-gnats address, it gets filed as a "pending" PR since it
isn't properly formatted as a bug submission, and doesn't get sent to the
lists, so few people see it.

Having a converter that converts current gccbug output (received by
gcc-gnats) into whatever format Bugzilla would expect for emailed bug
submission, and if appropriate a more Bugzilla-tailored new gccbug script
as well, is I think essential.  The detail of whether it then creates
Bugzilla accounts for the people who submit bugs this way I don't care
about.

Spam will not be properly formatted as a bug report from a bug reporting
script.  I don't know the best treatment of such mails that can't be
parsed as bug reports or follow-ups to existing ones, but perhaps they
should go to a moderator who discards them if spam or enters them manually
if relevant.

>   Bugzilla is currently back-ended into MySQL (see
> http://www.mozilla.org/projects/bugzilla/ ).  Dave Lawrence of Redhat
> has done an oracle port, see http://bugzilla.redhat.com/.  Dawn Endico
> made Bugzilla's XML DTD the industry-standard bug-tracking DTD (no
> standardization committee, but most open bug-trackers support the format
> now).  So you can do a mysql dump of data, export it via XML for
> importation elsewhere, or export your existing data to an
> easily-understood XML format for importation.
>   Bugzilla includes a "sanity check" to find basic database issues with
> data formats.  It's not comprehensive, however.  I recommend a good
> daily backup strategy for any Bugzilla database, which is covered in
> great detail at the mysql.com website.

OK, so the system could daily lock the database, do an XML dump and make
that available for rsync so we keep the bulk anonymous access to the whole
database, and back it up as documented?  (The FSF machines have reasonable
backup procedures, but I don't know about sourceware.)  Is the database of
bugs cleanly separated from other information such as user passwords (so
there are no security issues with having it available for anon rsync)?

>   I think it does pretty well, all things considered.  Is gcc using
> Savannah?  If so, we might have some nice "synergy" going here...

GCC isn't - though RMS would I think like it to use the FSF machines more.

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