The Fedora bug process

In a shockingly work-related post – this morning I got a bit inspired, and made extensive revisions to the Fedora bug process page.

Hopefully, nothing’s controversial, just a better documentation of the existing process. One significant thing it formalizes was discussed at the QA meeting this morning: what happens when a Rawhide bug gets fixed. It’s never really been clear if it must go through MODIFIED / fix confirmed by reporter before it goes to CLOSED. We agreed at the meeting, and I’ve written in the page, that it should be optional and up to the maintainer: if you fix a bug in Rawhide, you can either set the bug status to MODIFIED and ask the reporter to confirm the fix, or – if you’re confident and just don’t want the hassle – close it as CLOSED RAWHIDE immediately. It’s easy enough for the bug to be re-opened if the fix didn’t actually work.

Aside from that, I just re-arranged it in a more logical order, wikified it, and added a lot more detail on bits of the process, states, and resolutions that weren’t previously covered. It also now explicitly mentions which resolutions and states are valid for Fedora and which aren’t.

I’m expecting for this to be the definitive reference for the Fedora bug lifecycle. If that’s OK with everyone, I’ll ask for the page in Bugzilla – which, in practice, mostly covers RHEL – to have a note added which says it’s about RHEL, and to look at the Wiki page for Fedora. Trying to cover both different processes on one page would probably get rather messy.

2 Responses

  1. mcepl
    mcepl May 7, 2009 at 12:11 am | | Reply

    More and more I think about CLOSED/NEXTRELEASE lately. I always thought that it’s use is complete anathema … you just cannot say to reporter of Fedora {n}, that his bug is fixed in Rawhide (and will be released in Fedora {n+1}).

    Well, I am not sure about that as I used to be. Of course, we are talking only low- and medium- severity bugs, but I think we should be more frank about the real status of our bugs. Sometimes, we just want make new release for something silly.

    Just thinking.

You can comment without reCAPTCHA by using an OpenID as the URL, or logging in with an OpenID or an old site account.

Leave a Reply