Re: Bugzilla for GNOME (was Re: GNOME CVS: nautilus mathieu)

[Martin Baulig <martin home-of-linux org>]

Maciej Stachowiak <mjs eazel com> writes:

> I'm not arguing against it, I'm just pointing out that it's not that
> inconvenient to do it with the web interface. A basic email interface
> that allows bug submission seems like a must, one that allows
> administration of bugs seems like an extra, which might take a fair
> bit more work.

Well, that's not really a "must" anymore - it's almost an "already have"
now :-)

I'm currently working with a test installation which already does a fairly
good job on this.

However, it may not be exactly what people will expect since my plan is
the following:

The bugzilla.gnome.org installation, on the server side, will provide a
published and documented XML-DTD and there'll be a CGI script and an email
address to which you can send an XML file matching this DTD (so you can
use both email and http as transportation method).

There'll be three top-level elements in this DTD:

* <bug> - this is used to submit a new bug report; Bugzilla will reject
          all bug reports with any missing/wrong fields(*) and send back an
          error message.

* <control> - this is used to send control messages to the server, such
              as to close a bug report, to reassing a bug-report to another
              person etc.

* <error> - this is used by Bugzilla itself to send error messages back to
            the submitter (when you send bugzilla an XML file, it'll send you
            another XML file with this element in it back, but this'll also
            be used to signal success).

Later on, we can add two more top-level elements to this DTD:

* <query> - used to query Bugzilla about bugs

* <result> - used by Bugzilla to send the query results back.

Additionally, there'll be an XML file on bugzilla.gnome.org with information
about the Bugzilla installation, such as which packages/components exist etc.

That's all what we need to do on the server side.

(*) That's what client applications need to handle:

    If a user omits a required field, the client application may
    either require him to fill it out (Subject, Package, etc.) or
    provide a reasonable default (OS, Severity, Version, etc.).

    It's up to the client application to do this; but Bugzilla will
    reject all bug reports with missing or invalid fields (**), so the
    client application needs to provide reasonable defaults.

(**) To insert the bug report into Bugzilla's database; the missing fields
     need to be set, so we need to provide some defaults anyways. But this
     can be done much better in a client application, since such a client
     application can much better guess things like operating system,
     version numbers etc. and it's also easier to change a client application
     than the parsing script on the server.

Basically, we'll need three client applications:

* bug-buddy - this needs to be extended to write this XML file and
    to read the error XML file (which should never happen, since a
    client application must catch all missing/invalid fields and
    replace them with reasonable defaults, so if Bugzilla ever
    rejects a bug report, this is most likely a bug-buddy bug).

* halloween/sunrise - this are two little perl scripts I hacked this
    week and which are already almost finished.

    They'll read the data files from debbugs and output an XML file
    for Bugzilla - we'll use them to migrate all the old bugs from
    bugs.gnome.org into Bugzilla.

* some script which takes a mail message in a human-writable format
  and transforms it into a Bugzilla XML file and the other way around
  (parse the Bugzilla result XML and print human-readable error/success
  messages).

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)