This report is impressive… receiving 7,872 new reports and resolving 7,802 bug reports in a single month while continuing to hold a backlog of 46,000 open bugs! This says two things to me… they have a process for triaging and resolving bugs and they have a tremendous amount of people actively reporting issues.
In the past I’ve been skeptical about the size and effectiveness of Ubuntu’s community because the only evidence usually cited is distrowatch.com, googletrends, and glowing reports (I assumed biased) from Canonical employees at live events. I’ve never heard any hard numbers at the live events, just lots of enthusiasm about how things are “getting bigger and better” and that “collecting good data is hard”.
I think these bug stats are a great first step and show a lot of involvement and hard work. I wonder what the average run rate is per month? Is this regular monthly activity or the results of a special event for the recent release? I found a few more stats, but nothing that showed a corresponding monthly close rate. Without reporting the number of bugs closed each month it is hard to get a full picture.
These are Fedora’s run rates for the past year. For greater perspective look at the graph here.
I tend to think that comparing Fedora to Ubuntu as distros is an invalid comparison. Both projects have very different business and support models combined with different purposes. One thing both projects have in common is community. I am told that Ubuntu’s bug process is primarily community driven and this led me to wonder what Fedora can learn from Ubuntu about bug triage and bug handling.
Because I think there is enormous value in making sure our bug database is current and that we identify and track important release blocker bugs, I’ve been working for the past ten months to help jump start the Fedora bug triage process. We have made some good strides, but I think we are capable of more. Think what we could do with the remaining untriaged NEW rawhide bugs if we had more than three or four people at our weekly meetings? We need to energize our existing community and draw in new people to triage bugs, but the things we have tried to date haven’t gotten us very far.
If you have new ideas or want to help make a difference in Fedora, please join us at our weekly bug triage meeting on IRC, each Tuesday at 15:00 UTC (10 AM EST). We meet on the #fedora-meeting channel of irc.freenode.net.
Categories: Bug Triage · Fedora
Tagged: Fedora, ubuntu
A great observation came out of a recent bug triage meeting by David Nalley who noted that “there is great information about the HOW, but not the WHY or SO WHAT [of why bug triage is important].” I took an action item to try to define this better. We’ll be discussing this more at our weekly meeting tomorrow (Tuesday) on #fedora-meeting on irc.freenode.net @ 14:00 UTC (10 AM EDT). Everyone is welcome!
I went through the existing wiki pages to collect some reasons and also tacked on a few of my own. Feel free to add you our own in the comments or talk about it in your own blog about and link here. Here are my ideas so far.
Bug triage matters to Fedora because it:
- saves package maintainers time chasing down missing information in bug reports
- helps to identify bugs that should be fixed before release (adding to tracker lists)
- allows maintainers to spend their finite time on bugs that are ready to be worked on
- gives bug reporters the feeling that someone has acknowledged their problem
- strives to provide a level of certainty that the total number of open bugs is accurate
- helps to maintain structure in bugzilla by following defined processes to close bugs for EOL releases
- what else?
I suppose the possibility exists that some people think there is no value from bug triage. If that is your position, we’d love to hear your constructive suggestions for changes that would make it valuable. How can bug triagers help tackle some of Fedora’s 10,000 open bug reports?
Categories: Bug Triage · Fedora
Performing a network install of the Fedora 10 beta didn’t work for me because of the bug in the Intel e1000e driver. Using my local rawhide repo I built the ISOs to do a hard drive install from a separate partition which failed too. At that point I gave up on the x86_64 and went with a network install of i386 and box too old to need the e1000e driver.
The only smooth part of the process was creating the DVD ISO using a local copy of the rawhide (development) trees for a majority of the bits.
Here is how I did it for the x86_64 DVD ISO:
1) Go to http://fedoraproject.org/get-prerelease
2) Click on jigdo link for desired arch and save two files to your system
Fedora-9-x86_64-DVD.jigdo
Fedora-9-x86_64-DVD.template
Downloading the template file too saves a little time because the first step jigdo does is search for it on a mirror. Make sure you are working in a filesystem with plenty of space and make your local package repo or install tree accessible as a filesystem:
- local hardrive directory
- nfs share
Based on my experience jigdo cannot access files on a local network with http, though I suppose you might be able to configure jigdo somehow to consider it a mirror.
4) Start the process:
$ jigdo-lite Fedora-9-x86_64-DVD.jigdo
5) Answer the prompt by pointing it to the location of your local repo
Jigdo will scan your local repo and pick up as many local packages as it can and then return you to a prompt for another location to search. After you have exhausted your local options hit return and it will go out to the mirrors and look for the remaining packages.
The way to do the least amount of downloading for missing packages is to make sure you have a good sync of rawhide a day or two before release day. Or in my case remove the --delete flag from rsync so as to preserve previously downloaded files.
All told the process took approximately 50 minutes to scan my local repo, download 20 missing files, and build the DVD ISO image and used very little bandwidth.
Categories: Fedora · Linux
