bugathons:january2008

This is an old revision of the document!

Agenda

MarkLinimon has gathered together a large number of emails and IRC conversations during January 2008 (and some previously) and needs to edit them up and present them. However, as of 20080121 this isn't in a state that is ready to present. Here's some things we need to do to start.

  • [wiki:self:BugBusting/Volunteers 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 wiki pages (such as [wiki:self:BugBusting/Resources BugBugsting Resources ] 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 [http://www.freebsd.org/cgi/cvsweb.cgi/src/ 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.

  • Start thinking about more categories for PRs. See below.

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:

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.

MarkLinimon will take the action item to figure out how to push the changes we make out to everyone's systems.

  • bugathons/january2008.1201236013.txt.gz
  • Last modified: 2008/01/25 04:40
  • by MarkLinimon