Fate of the attachment status patches

To recap, bugzilla.gnome.org (henceforth bgo, of which I am nothing but an enthusiastic user) is running a rather heavily patched version of Bugzilla 2.x. One of the changes from 2.x is a system to let people set a patch’s status using a drop menu from any one of a number of options (including “obsolete”, “reviewed”, “rejected”, “committed”, “commit after freeze”, and so on), rather than simply the boolean “obsolete” or “not obsolete”.

In the meantime, Bugzilla 3.x has evolved a separate system of flags for greater control over a patch’s status, so that you can have a number of not-quite-boolean flags set on or off or maybe for each bug.

There is an idea, tracked as GNOME bug 433607, that bgo should switch to Bugzilla 3.x, which would be lovely and allow a lot more fun things such as XML querying of bugs, which is something I really want. Last year sometime in 433607 I said I would have a try at porting the bgo status system over to 3.x, and I’ve finally had time to do that over the last few days. Here’s the result.

However, I put this into Mozilla bug 431438 which was immediately marked as a duplicate of Mozilla bug 353690, which is saying that flags (in the 3.x sense) should be able to have arbitrary values. This won’t be released for another year until Bugzilla 4.x. So I suppose either we stick with 2.x, go to 3.x but apply the patch locally, go to 3.x and find a provable way to convert all existing statuses to 3.x flags, or wait for 4.x.

Lychee tea keeps me going!

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

5 thoughts on “Fate of the attachment status patches”

  1. Just reopen it and clarify the point. Put it this way, which one is more effort: attempting to correct some overzealous triaging, or maintaining a fork for a year? That the final solution isn’t the same as the one you’ve given doesn’t preclude it from being adopted for now.

    – Chris

  2. Attachment statuses are the system that preceeds flags in upstream Bugzilla, actually. That is, apparently bgo liked the old system, so when we switched to the new system, they forward-ported the old system from old Bugzilla, with a slightly different UI.


  3. Hm, the plot thickens. Thank you.

    I think I’ll leave it for the moment until bgo admins say what the best way forward is.

    I’m still not sure how the 3.x system would support the distinction between “not committed”, “ok to commit”, and “ok to commit after freeze”, though perhaps that’s not an important distinction to make in general, because it can be explicitly spelt out in the comments.

  4. Spelling it out in the comments really doesn’t help; there needs to be an easy way to search for such patches after freezes open up.

    Also, we forward-ported the *improved* version of the old system from old bugzilla, because it’s vastly easier/quicker to use. For b.m.o., fine-grained reviews and control is important (thus the flags make sense), but for b.g.o. it’s irrelevant and thus easier/quicker was a big winner. I’d be really sad to see us move to flags; we intentionally ripped them out of the UI for b.g.o.

  5. Elijah: Who was your first paragraph aimed at, Chris or me?

    And who is freezing? I’m a bit confused.

    It seems to me that
    * bgo are unlikely to move ahead without status
    * bgo are unlikely to accept a status patch without it being accepted upstream at bmo
    * bmo won’t accept a status patch because they prefer flags

    So we seem to be at a bit of an impasse.

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *