I’ve just tallied up the fedora kernel bug count for release 7, 8 and devel – 759. Then I looked back to mid-november – 756. Still, things are improving. There has been a resurgence in the fedora triage effort with some debate on fedora-devel as to how best tackle the issue of a growing bug count in Fedora. Jon Stanley and John Poelstra in particular have been getting active and thrashed out some ideas at FUDCON, which I was unable to attend but have made it a priority to get to next year.
Anyway, I digress. As Linux becomes more popular, more people file bugs. Soon maintainers of large packages such as the kernel, openoffice.org or firefox get lost under the crashing weight. So here’s how the process works.
Someone files a bug – it comes in under category NEW.
The triager (or a maintainer if they are able) reviews and either requests more info (sets bug to NEEDINFO) or accepts the problem and sets to ASSIGNED.
The triagers work is then done. Other states such as ON_DEV exist where the maintainer can acknowledge he is working on a solution. There is also:
MODIFIED – fix is available for testing
ON_QA – fix is being tested
NEXTRELEASE – fix has been confirmed as working and will arrive in next release
Ultimately bugs end up as INSUFFICIENT_DATA where the original reporter could not provide the information or has since lost interest – I consider this the least favourable resolution. CURRENTRELEASE is the golden goose where the fix has been approved and all parties are happy. About 25% of F7 kernel bugs have ended up in this state. See diagram below – the current state of F7 kernel bugs.
Bug triaging is an excellent way for those who know the basics to get further into Linux and start learning about various parts of the system and teaches more than a year of system administration ever could. I commend it to the house!