Date: Thu, 10 Jan 2008 21:02:23 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Garrett Cooper <youshi10@u.washington.edu> Cc: Tom Evans <tevans.uk@googlemail.com>, Joao Barros <joao.barros@gmail.com>, freebsd-current@freebsd.org Subject: Re: Addressing the pressing performance / bug issues (was "FreeBSD's problems as seen by the BSDForen.de community") Message-ID: <20080110205452.M4766@fledge.watson.org> In-Reply-To: <47865FDA.1020006@u.washington.edu> References: <478556AD.6090400@bsdforen.de> <20080110003524.GB5188@soaustin.net> <4786167D.7060202@freebsd.org> <70e8236f0801100739r4ea9f4a0nf8734d8f3bb9f31e@mail.gmail.com> <1199981082.1713.6.camel@localhost> <47865494.7030304@freebsd.org> <47865FDA.1020006@u.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jan 2008, Garrett Cooper wrote: > I've been reading the thread a bit (glossed over the licensing political > drumming), and I realize that yes there is in fact a need for addressing > issues. Would it be a good idea to compile a series of bugs using a > prioritization system based on interest (number of stakeholders) and/or > funding (say Cisco or Intel devotes X number of dollars for a feature)? I > would think that that would be an effective system for gaging priority > perhaps. I suspect that of all the stakeholders in the community, the Ciscos, Junipers, etc, of the world are the ones who will get their problems addressed most quickly, on the basis that while OS developers are expensive, they're not all that expensive. The people who tend to do least well are the individual end-users who don't have the technical know-how to engage with developers who have, on occasion, been known to have poor personal communications skills, not to mention a day job. The most common classes of problems that tend to go unsolved are the ones involving pseudo-random combinations of hardware not in the hands of developers, less common configurations using networking tehnologies that aren't as widely deployed, and aging hardware -- the precise types of problems that big companies try to avoid (especially minimizing hardware footprint). It seems to me that we have structural, procedural, and social areas that need addressing with respect to how bug reports are handled. We need to manage and present them better (no one needs to rant about GNATS, we all know it leaves much to be desired), and we need to build up a better social model regarding how we handle reports. For example, how about we have a web page that shows the most recent 50 GNATS bug reports in a single click? Or a way for the RE team to flag potentially interesting issues for releases so that developers (and end-users) can look for things to work on? The problems are similar to problems regarding code review: how can we get people interested and engaged in debugging problems, and how can we improve the tools to make it happen more smoothly? I like the idea of Bugathons, we should see if we can't get more people involved in that as well. Finally, I think there's a set of people in the FreeBSD project who really deserve our thanks -- that's the people (and there are several) who watch new bug reports come into GNATS and attempt to sort them, triage them in various ways. Turning "my machine crashed" into a usable bug report requires a lot of dedication from these folks, and we should be doing whatever we can to support and help them, including trying to find more volunteers to work on that project. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080110205452.M4766>