Bugzilla workflow - the way forward

Most of this content is going to make it's way on to the Fedora wiki in the next 24-48 hours and an announcement to fedora-devel-announce shortly after it winds up in final form on the wiki. In the meantime, I thought that it would be beneficial to get a draft out there. -- As many of you know, I have been working on relaunching a triage team within Fedora (more on that later as we come closer to a formal launch - there's lots of things that we need to do before we announce that to the world at large). Part of the effort is streamlining the current Bugzilla workflow (or lack thereof). These workflow guidelines were approved at the FESCo meeting on January 24, 2008. Note the use of the word guidelines, these aren't hard and fast rules that we are imposing on people. If you have a good reason to break them, feel free - but this is the mantra that the triage team will be going by. When a reporter enters a bug, the report automatically starts out in a NEW state. The triage team will be primarily looking at bugs in this state. From this state, the triage team can either change the status to ASSIGNED (which indicates that the bug is well defined and triaged), or use the NEEDINFO state to request additional information from the reporter, or close the bug (either as a duplicate of an existing one, or using other closure reasons - CANTFIX for problems with proprietary drivers or kernels that have such drivers loaded, for example). The ASSIGNED state is a state that has a new meaning - it used to mean that the bug was actually assigned to a person. Instead, it now means that the bug is capable of being worked on by a maintainer - i.e. the triage team believes that this is a complete, actionable bug - i.e. with a stack trace for a crasher, various log files for other components, complete AVC message for SELinux stuff, etc. When a maintainer has a fix for a bug checked into CVS, they should move the state of the bug to MODIFIED. This is an indication that the fix is indeed in CVS, and has likely had a build submitted against it. You may want to (though it's certainly not required) post a link to the koji build so that the adventuresome tester can go grab a copy and verify the fix. Once a maintainer submits an update via bodhi against a particular bug, and the update hits updates-testing, the state of the bug will transition via bodhi to ON_QA. This is a indication to the reporter of the bug that there is a fix for the bug available, and that they should test the package that's in updates-testing, and report on it via bodhi and/or as a comment in the Bugzilla. The comment used by bodhi will be more verbose as to how to give feedback via bodhi. Another change in the current process is that once the update from bodhi hits stable, the bug will be automatically closed. There used to be a checkbox in bodhi not to auto-close the bug - this either has been or will soon be removed. It is therefore important that one bug describe one issue in one release. If the same bug applies to multiple releases, then multiple bugs should be opened (possibly using the clone feature of bugzilla). The final change is that NEEDINFO bugs are eligible to be closed by the triage team (after review that the information has not been provided, that it's not the maintainer that the NEEDINFO is requested of, etc) after 30 days of inactivity. A stock message will be provided to triagers (yet to be written) with which to close these bugs. Sorry for such a long e-mail, I just wanted to make certain that everyone was informed of these changes and an impending launch of the BugZappers! Subject line shamelessly stolen from Max and adapted :)

Fedora bug triage - workflow ideas/proposal

I just sent this over to fedora-devel-list for input and comments. Anyone out in the world that cares is also welcome to comment :) Well, it was a great session at FUDCon. A lot came out of it, and I'mgoing to put some of them down here. The work flow suggested below I'd a FESco vote on, since it really affects you guys. This work flow was discussed between myself, John Poelstra, and Will Woods at the Sunday hackfest, and we agree that this is the correct way to move forward, however, we want community input and buy-in on this, since it has pretty far-reaching consequences. Here is the lifecycle of a bug: 1) Reporter files a bug report, it originates in NEW state 2) Triage team looks at bug report, determines if dupe or insufficient information exists to solve it. If there is not enough information in the bug, then triage team puts the bug in NEEDINFO. As you will see below, this state has a finite life cycle associated with it. 3) Assuming bug survives through the triage team, it changes state to ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as appropriate). Note that per the definition[1], ASSIGNED does not mean that someone has actually agreed to take action, simply that the issue is well defined and triaged accordingly 4) Once a developer has taken responsibility for a bug and is actively working on it, the state transitions to ON_DEV. 5) Once an update addressing a bug exists in Bodhi, and is pushed to updates-testing, the status automatically transitions to ON_QA 6) When the update is pushed to stable, Bodhi optionally closes the bug automatically. If the update does not auto-close the bug, it transitions to NEEDINFO_REPORTER, with a comment explaining that the update has been pushed to stable, and to update and test in the new release. Note that at any step of the above process, the maintainer can "fast track" the bug, and change it to ASSIGNED. The triage team is not going to look at bugs that are not in NEW or NEEDINFO state. On the flip side of that, it is not a maintainer's responsibility to look at bugs that are in NEW any longer. They can focus their energy on the bugs that are ASSIGNED to them. Also, maintainers should not be allowed to set priority on bugs. Setting severity is fine. Only QA or releng should set priorities. This allows us to look at things in a sane manner (which is impossible now since severity and priority fields come from /dev/urandom seemingly), and possibly lessen the reliance on blocker bugs (though blockers are useful in their own right, so don't think that we are going to eliminate them any time soon). It was also decided that when a bug is in NEEDINFO for one month, it will be closed. Maintainers would need to realize that putting a bug in NEEDINFO is putting it on the fast track for closure. I think that's all that I have to say on this topic right now, let me know if I'm missing anything or this is complete hogwash :)

FUDCon - home at last (barely)

Well, I had a really great time at FUDCon in Raleigh. However, I almost ended up staying the night in jail rather than at home. Here's what happened. and I feel absolutely horrible about it. I decided that the weather was getting bad here in NYC, so I figured that I would take a cab home. Turns out, that's $80 + toll + tip, so I figured that I wouldn't do that. I figured that I would take the cab to the nearest public transportation hub that's in the city to my apartment - that's the PATH station at 34th and 6th (it's going outside of the city limits that costs so much, since they can't pick anyone up over here). Most cabs in NYC now have credit card machines in them. This one didn't, and it turns out that's what killed me. The driver said "that's fine, you can stop by the ATM on the way". Sure, not a big deal - just drop by the ATM and grab some cash. Except for I didn't have any money in my checking account. Now, I had no reason to believe that I didn't have the money (which I should have - hindsight is 20/20 as they always say). I had firmly believed that I had booked my hotel room at FUDCon using awards points, When I got the bill this morning, imagine my surprise to find that I had been actually charged for the room. Being stupid, when I checked in, I plopped down my debit card (since this was supposed to cost me nothing). I thought that was really bad, but not the end of the world. Apparently it WAS the end of my checking account. Now, I have two checking accounts - one that I use daily, and another one that I pay the rent out of (and throw a few hundred extra bucks a month in there). They have two separate ATM cards. Having no reason to carry the extra one with me, I don't (that will likely change as a result of this - but there's another reason that I don't carry that card with me - protection from if I lose my wallet I can transfer money around and just use the other account until a new card gets to me). So I go to the ATM, it won't dispense me any cash, so I get in and inform the driver of this. He proceeds to take me to my destination, but then tells me that he'll have to call the cops if I don't pay him. Since I have no method TO pay him without a bank nearby that's open at 10PM to give me a cash advance on a credit card, I offer to call the cops FOR him - heck, maybe they could think of something that was escaping me before hauling me off to jail. He tells me not to do this, and proceeds to give me a tirade about how he's just trying to make ends meet, that I actually have some supply of money that I'm not telling him about, etc. I think I made it clear that I had a desire to pay him, but it wasn't something that I was able to do exactly that moment. I told him to give me his phone number (which he did not do) so that I could make things right with him, since he doesn't need to pay for my stupidity (there would have been a fat tip in it for him too, but oh well....his loss I guess). I gave him what cash I had ($27 for a $36 ride), and he admonished me to make sure that I actually had money before getting in a cab next time. Now, if the cab would have had one of those credit card machines in it, I could just put it on one of the 3 CREDIT cards that I carry with me, and everyone would have been happy. But I don't have a PIN those cards for getting cash at an ATM, because, well - I should never have to. In hindsight, I will NEVER make what could possibly be (but is not supposed to be) a large-ish expense on my debit card, and I'll probably start carrying some "emergency" cash when I travel - I hate carrying cash with a passion, though - I pay for EVERYTHING using my debit card). I also should have checked my checking account from FUDCon since I knew that it was a large expense that I hadn't planned on - I could have transferred money between my two accounts right then and there, and alos not had a problem. Oh well, you live and learn, I guess. I tried to get into contact with the company that owns the cab (there's a public list of medallion numbers and owners), but there's no listing for them. I called 311, and they told me that they're not directory assistance. Oh well, I tried. Still feel horrible about the whole thing, though - I'm not the kind of person that stiffs someone.

Fedora Bug Triage - FUDCon session notes

All that I can say about the session that I just hosted at FUDCon is - wow. I had no idea that there were so many people that believed in what I'm trying to do here (and really no one other than me willing to lead it, since being a leader takes hard work) - the room that sat around 20-ish was standing room only. A few ideas came out of the meeting, some of them are below:

• Go to a sponsorship system for fedorabugs in FAS - not really a problem
• Require CLA for triage - not really necessary, per se, however we believe that the barrier of entry of being able to sign the CLA will weed out the people who are not technical enough to be able to do this.
• NEEDINFO bugs should be closed after a month with a canned comment.
• The reward system received some good input
• We'll be having meetings on IRC, but the time is to be determined.
• Wiki needs to be cleaned up regarding triage - we're going to start on this tomorrow.

The one thing that I wished would have been different about the presentation is that we had more time for it. We had time to get through about half of what we needed to do and what the interest was there for. Hopefully the hackfest session tomorrow will lead to some closure on a lot of this. In retrospect, I should have come to the hackfest on Friday as well, and I would have had some more ideas coming into today. Oh well, as they always say, hindsight is 20/20.

It's official - a new fearless leader

Well, it's official now...we have a new leader of the Fedora project. The new leader is Paul Frields. I'm new to the Fedora community, however have been welcomed to the organization by Paul. I would like to welcome Paul as the new leader, and thank Max Spevack for what he has done for the project - he's done a number of things for the project, including the merge of Fedora Core and Extras, and the movement of Fedora infrastructure outside the walls of Red Hat and into the hands of the community. More to come tomorrow.

Linux is not about choice

There was an excellent thread today on fedora-devel-list about the common misperception that Linux is about choice. While it is true that in Linux you have lots of choice, the point is not to be about it. You have a choice about what kind of car to drive too - does that make car buying all about choice? No. You pick the car that best suits you and has the right mix of features. That is the same attitude that you should apply to the selection of Linux distributions. Once you select a distribution (hopefully Fedora :) ), then you have no choice except for the distributions (which unlike proprietary software, you can have a say in the direction of that software) you should follow the direction of the software. For instance, the selection of the new FireWire (IEEE 1394) stack was what brought this discussion on. A distribution should select one particular technology to go with (and Fedora, being a leading edge distribution, will quite often select the latest incarnation, even if that is known to have bug, and prefer to fix the bugs preferably before release into stable, but definitely paying attention to the bugs that are filed (more on the bugs part in another post). Well, this post has been sitting around forever in my drafts. In the meantime, Jesse Keating did another, similar, post in Red Hat Magazine that's 20 times better than this one.. I just wanted to reemphasize something that Jesse said in that post: At the end of the day, Linux is about user choice. And without the users, we have nothing. If you don't like the choices that Fedora has made, you have three choices (geez, we even give you choices of how to deal with the lack of choices in Fedora!) of how to deal with that (listed in order of preference): 1) You get involved in Fedora, and try to convince people why your choice is the right one. 2) You choose another Linux distribution (Ubuntu, openSUSE, Gentoo, etc) 3) You use another operating system entirely (Windows, FreeBSD, whatever). Obviously, we would prefer the first one, the second one is OK too. The third one is what we'd prefer to avoid :).

More thoughts on Fedora bug triage

Well, I've been meaning to post some additional thoughts on the state of bug triage in Fedora. However, there's such a interest from the community here that I've setup a wiki page for it here. If you are unable to modify the wiki (requires a Fedora account and some other stuff) then PLEASE post comments here. I'm going to post a link to this post on the wiki page as well.

State of Fedora bug triage - some thoughts

I've recently started doing bug triage for the Fedora Project. I figured that I would be joining others in doing this - however, found that the state of affairs was pretty sad - there's no defined leadership, no guidelines for participation, etc. Here's a general list of what needs to be improved:

• Defined leader to be established (I volunteer for this task)
• Establish weekly meetings on IRC
• Establish official procedures for becoming a traiger, possibly including a sponsorship system such as other Fedora projects to ensure quality triage, though I do not want to create an excessive barrier to entry.
• Interface with core maintainers of various packages
• Interface with Fedora QA inside of Red Hat
• Interface with Fedora board, various Steering Committees, and other relevant parties.

Some ideas that have come up from the community are below: A separate bugzilla instance for Fedora (I don't think that this is especially workable or desirable) Incentives for triaging Breaking triage out into individual development teams/projects More to come.