(Note: this is now of historical interest only)
Results
Over 30 people participated in this bugathon. Thanks to all who participated!
During the 3 days, we closed around 120 PRs, and probably 50 more were set to feedback. Of course, during this time about 80 PRs came in (including some ports PRs). While the net reduction doesn't look that large, it does constitute positive progress -- a large number of stale PRs were indeed closed, and a few were committed. For our next bugathon we'll try to be more focussed on committing some of the PRs that we've already identified, and also to keep a count of PRs busted by category (which we had done before, but forgotten to get a volunteer for this time.)
Agenda
MarkLinimon gathered together a large number of emails and IRC conversations during January 2008 (and some previously) but wasn't able to get them into a state that was ready to present. Here's some things we did to start.
sign up new volunteers. We have had a great deal of interest from people wanting to know "how can I help". To start with, we should gather information about levels of expertise and interests.
Make sure that everyone has a chance to look at the new bugbusting wiki pages (such as Resources and Tips and Tricks so everyone is informed about what already exists.
- Try to see if we can get any committers interested in mentoring someone for e.g. bin/ PRs.
PRs in the 'patched' state. These represent code changes that have already been committed to whatever represented -CURRENT at the time, and have been flagged as needing merges to a release branch. Many of these have probably already been merged. Someone who is interested can look through cvsweb and determine whether or not this is the case. For ones that have, they can be closed; for ones that have not, whoever committed the change should be notified. (Usually they have the PR already assigned to them, but not always.)
- Note: it is too late in the 7.0 release cycle for anything to be merged to it; however, it's reasonable to think we can merge things to RELENG_7.
RobertWatson has suggested that searching PRs for "dfilter@FreeBSD.org" would show PRs for which fixes have already been committed. Some of those may not have made it to the 'patched' state.
- Note: it is too late in the 7.0 release cycle for anything to be merged to it; however, it's reasonable to think we can merge things to RELENG_7.
Start thinking about more categories, states, and classes for PRs. See below. (MarkLinimon will take the action item to figure out how to push the changes we make out to everyone's systems.)
PR categories
Right now the kern PRs are far too monolithic. At the very least we need to break that up. This might make it easier to start seeing patterns.
Originally, MarkLinimon was of the opinion that we should wait to break up the categories until we had a really clear idea of all the ones that we wanted. However, this was probably a bad idea: we should try some experiments and see if we can make something better than what we have. (This would also carry over to any future bugtracking system.)
We can think about breaking them up by existing mailing list as a first approximation. We already did this for usb some time back; it seems to have helped. Possible ideas:
acpi -> freebsd-acpi
drivers -> freebsd-drivers
fs -> freebsd-fs
geom -> freebsd-geom
net -> freebsd-net
pf -> freebsd-pf
rc -> freebsd-rc
It's harder to come up with how to categorize the following:
- "can't install FreeBSD"
- "system does not perform well"
- problem that is hard to isolate to one part of the code
Ideas for naming are welcome.
Another observation is that the arch-specific categories are always misunderstood. New users seem to believe that "oh, my machine is an i386, so I'll file any problem I have with it there." At least half of the new entries there are misplaced and have to be refiled. Almost all the others are "can't install on this machine/can't boot on this machine". Only a few are actual arch-specific problems, and they are so tagged (e.g. [amd64]). Should we just get rid of these categories? Or jam them together as 'hardware-specific'?
Another category that should be added is "stuff that affects the build process/Makefile glue/etc." What's a good name for this? 'infrastructure'? Seems too long.
All of the PRs that come in as 'misc' are either 'infrastructure' (very small number) or "I don't understand how the PR system works". The latter all have to get reclassified to keep them from getting lost.
PR classes
- definitely need to add 'feature-request'. 'change-request' is too vague. There are a lot of PRs that can be put into that class. (It needs to be a class, not a category, because you can be making feature requests for any category.)
PR states
- 'confirmed' and 'approved'. The latter means that a committer (or, for ports, maintainer) thinks it's ready to go. The former is more for "xyz doesn't work" or "foo has regressed". 'analyzed' is too vague. (should we even keep it?)
- refactor 'closed' into 'closed/fixed', 'closed/not supported', 'closed/pilot error'?
Interesting PRs
A list of problem reports which people on IRC have already investigated and suggested, commented something, but not resolved yet, is online now at Bugathons/January2008/InterestingBugs