Re: Bugs in Bugzilla

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

Maciej Stachowiak <mjs eazel com> writes:

> I wouldn't mind hearing about it if someone has a crash, even without
> contact info, but I don't want that mixed up with the real bug
> reports.

Well, I think it's a bad idea to use a simple debbugs wrapper as the
_default_ for bug-buddy. If we do this, we'll just waste a powerful
resource - the resource to get good bug reports from people who actually
want to submit good bug reports.

I think we should install two things:

1.) A simple debbugs wrapper which submits all bugs under some
    submit bugzilla gnome org email address or something like this and
    puts the real From: line into the first line of the bug description.

    This'll still allow people to report a bug by simply writing an email,
    but also make it very easy for the module maintainer to silently drop
    all of these if they get older than a month.

    It must be allowed by policy to silently drop all of them without
    notice and without giving any reason.

2.) An enhanced form of 1.) which is much more strict and works about like
    this:

    - you send a mail to some address and you get some kind of "mail form"
      back which you need to fill out.

    - this mail form consists of three parts:

      a.) instructions on how to write a good bug report, where to get help
          and how to fill out that form.

      b.) the form itself which should be in a format which is both easy
          to parse, but still allows people to easily edit it by hand.

      c.) an identification number which is used to validate the email
          address so the reply will be filed as real bug report.

    This can also be extended to let people query for existing bug reports
    or submit additional information to existing bug reports.

Both 1.) and 2.) can be done as wrappers around 3.):

3.) An email interface which takes an XML file as input and files it as a
    real bug report. This will only work for people who have a Bugzilla
    account (we can either just use the From: line to verify this or send
    a hash of the password or something like this in a X-Bugzilla-Password:
    mail header), but let them submit a real bug report.

    This interface will be very strict and only allow correct XML files
    which contain all the required fields, but it is not intended to be used
    directly.

The second one is not really required for the moment, but I think we'll need
1.) to migrate all the old bugs over and 3.) will be what bug-buddy should
use as the default.

> Unfortunately some kind of registration process is the only real way
> to validate an email address. It may be true that the password is
> overkill, though.

Well, I think when we add Bugzilla support to bug-buddy we can allow people
to put their password into some ~/.bugzillapass and then include it in the
bug mail (either in clear or some hash or something like this) or even let
Bugzilla just look at the From: line.

> > Although, if we do have one for "bugs" and something (that bug-buddy
> > sends to) for "problem reports", then this isn't an issue. The only
> > issue then is that someone is going to have to wade through the
> > "problem reports" and promote them to "bugs" if applicable. And if
> > there's that much volume involved and lackluster maintainers or
> > problem-report-people, then what do we gain, really?
> 
> Well, the lower-quality problem reports will by default not drown out
> the bugs. A lame person looking at only the bug reports and ignoring
> the problem reports is a win relative to a lame person not looking at
> anything because of the sheer volume.

I think we can't just assume that people don't want to use the "real"
Bugzilla interface; most users do want to submit good bug reports, so
most likely these "problem reports" will be "it crashed"-like ones anyways
which we can just ignore if noone looks at them in a reasonable timeframe.

> One interesting thing to note is that most large proprietary software
> companies have two levels of bug tracking. There's an external system
> where users submit trouble tickets to support, and only support, QA
> and the developers can generate bug reports in the real internal bug
> tracker seen by developers. When support turns a trouble ticket into a
> bug report, they create a cross-reference. I don't think we should do
> something like that for Gnome, but it's something worth noting.

Well, Bugzilla has this option that newly reported bugs are all NEW and
need to be ASSIGNED to someone before they become "real" bug reports.

Hmm, this reminds me:

How do you think should we do this with the maintainers; I mean, Bugzilla
lets you assign a bug report to a person (which is identified by a bugzilla
account), but with the old bug tracker we had our <package>-maint gnome org
maintainer lists.

Maybe we should create <package>-maint gnome org Bugzilla accounts and
let package maintainers use them instead of their own accounts.

How did you solve this in the Eazel bugtracker; I think you also have more
than one person who's responsible for each product/component ?

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