Re: Bugzilla summary

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

Telsa Gwynne <hobbit aloss ukuu org uk> writes:

> Agreed: NOTGNOME is very clear. INVALID is less so and sounds more
> like a brush-off ("You say it's a bug, I say it's a feature/designed
> that way/a property of the library and can't be changed.") 

Since you're now the 2nd one who wants NOTGNOME, I don't think having both
NOTGNOME and INVALID makes much sense (since we already have INCOMPLETE),
but maybe we should keep both of them anyways (for real "trash" stuff, such
as SPAM or stuff which really isn't a bug report at all).

What do you think ?

> > >8.) Did I miss something
> 
> Two-fold: 
> 
> (a) what's going to happen to bugs.gnome.org? It will be around for
> a few years but deprecated, and it will feed stuff into the new
> Bugzilla?

I don't think it's required to keep it so long alive.

>From a technical point of view, keeping it 2 weeks is already long enough
since Bugzilla will have all bug reports from bugs.gnome.org - but since
there's also no reason why we should shut it down, we can also keep it
as long as we want.

> (b) if the above is not the case (and I hope it is the case), provision
> for (sorry, but I have to bring it up) emailed reports? People have
> mentioned that Bugzilla has an email interface in its /contrib directory:
> did you install it, or not? 

No, I did not install it, it is a piece of shit and does not work.

That's why I started to write a new email interface which will be more or
less as powerful as the old debbugs one (at least, it'll allow you to submit
bugs in debbugs format and run basic control and query operations).

This stuff is half-way working, but I cannot finish it before we have the
final Bugzilla setup and fields, projects etc. won't change anymore.

So my time frame is something like this:

* Milestone I : hopefully one week after we finished this discussion:

    - Bugzilla will be up and running
    - You will be able to submit bugs to it online and work on the bugs
      online
    - There'll be some documentation which tells maintainers how to use
      Bugzilla etc.
    - Bugzilla will be the recommended way to submit bugs, but bugs.gnome.org
      will still be functional and all email will still go there.

    At this point I need to make a "hard freeze" on the Bugzilla configuration
    and copy the whole thing to a second installation which I'll use for
    testing

* Milestone II : hopefully two or three weeks after Milestone I

    - halloween.pl / sunrise.pl and the XML import/export will be finished and
      import the whole debbugs database into the test installation

    - bugs.gnome.org still working at this time and getting mail

* Milestone III : a few days after Milestone II

    - the debbugs email -> XML parser script will be finished

    - bugs.gnome.org will stop accepting new bug reports, but automatically
      forward them to Bugzilla

    - bugs.gnome.org will still be the only source of the old bugs and you'll
      still be able to modify them by email (not yet read-only).

    - Maintainers will be able to request that all their bugs are copied over
      to Bugzilla right now (but this'll mean that they'll be responsible for
      keeping track of all state changes etc. in debbugs for their package).

* Milestone IV : one or two months after Milestone III

    - Applications like bug-buddy will be ported to use Bugzilla and the new
      XML-based email interface.

    - Someone will have written a "email in human readable form" -> "email
      in XML format" converting script (for the control / query operations).

* Milestone V : together with Milestone IV

    - bugs.gnome.org will be set read-only and stop accepting any new mails.

    - the big import will happen

It's up to discussion when Milestone V will happen - technically, it only
depends on Milestone III, but not IV.

To make this clear:

"First Milestone IV, then Milestone V":

        Advantages:
                A fully functional email interface will be in place before
                you cannot modify bugs in debbugs anymore

        Disadvantages:
                It may take one or two months until we get all the old bugs
                from debbugs in Bugzilla (debbugs must be set read-only before
                the import, otherwise we'd loose state changes (such as, closing,
                reopening or submitting more info) in debbugs which happen after
                the import)

"First Milestone V, then Milestone IV":

        Advantages:
                You will have a fully working Bugzilla quickly with all the
                old bugs from bugzilla

        Disadvantages:
                You can submit new bugs per email, but you cannot modify any
                bugs per email or submit more info on them until Milestone IV
                is completed.

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