Date: Fri, 23 Feb 2007 18:19:42 -0800 From: Lyndon Nerenberg <lyndon+@orthanc.ca> To: Tom Rhodes <trhodes@freebsd.org> Cc: bugbusters@freebsd.org, Remko Lodder <remko@elvandar.org> Subject: Re: status? Message-ID: <100081FA-6B1E-43A5-A447-A9ABFE5A44E6@orthanc.ca> In-Reply-To: <20070223195750.5e82a475.trhodes@FreeBSD.org> References: <45DF47A1.3020305@elvandar.org> <20070223195750.5e82a475.trhodes@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Admittedly so, I'll probably pull my hair out and scream if > I need to look over each and every document in our tree and > garbage collect 4.X stuff - updating and finishing parts as > I can. I think too much emphasis is place on the release the bug is reported against. Most userland bugs are independent of the release version. Yes, that's an anecdotal claim, but it's based on over two decades of fixing bugs in applications, kernels, and everything in between. I think the problem boils down to the fact that the bug fixers mostly fall into two classes: 1) FreeBSD core, or close to it, and 2) Relatively inexperienced UNIX programmers who see bug whacking as a way to obtain knowledge through experience. When you are the recipient of their efforts, it is very easy to classify them. A category (1) bug buster says "no patch provided/ patch doesn't compile against current/style bugs/etc." A category (2) bug buster says "is this still a problem" without even reading the bug report. I exaggerate case (2) to a point, but only just. Case (1) is understandable. Those people are *busy* and will use whatever means at hand to filter out what they cannot immediately work on. But the consequence of this is that anything not directly related to the vacuum-edge-of-space version of -current they won't touch. Fair enough. Case (2) is also understandable. These tend to be people with little experience doing in-depth problem analysis, a lack of familiarity with the relevant standards, and an abundance of enthusiasm to help the project. The latter draws them in, then the former scares the bejeezus out of them. We need a category 1.5: people with both the time and experience to pick off a PR, spend some time reading and *understanding* the issue, and then proposing or applying a fix in the context of both the original PR and the current state of the release tree. To fill this role you really need to be a generalist. You must understand the whole UNIX philosophy, you need to understand the design goals of FreeBSD, have more than a basic familiarity of the relevant standards, and not be afraid to stand up and defend the decisions you make in the face of criticism from people who have a scary amount of knowledge. These people exist. So why can't we seem to get them on board. My opinion is that the mentoring process to becoming a committer is too opaque. And perhaps not granular enough, although that granularity is primarily dictated by the source code management system. Regardless, I have time and time again seen new people come on board wanting to whack bugs down, only to burn out within weeks, if not days. Clearly there is something wrong with the process. And it could be as simple as the project setting unreal expectations for the newcomers. I don't have an answer for this. > In the case of PRs (both code and doc), the process is much > more in depth. While I'd like to say "just close them and > wait for another PR for 5/6/7" that is just bad handling. And as an example, I will quote a biased example: bin/7868 7+ years and counting :-) > So my opinion is just coming up with some kind of .plan for > dealing with them. It could as simple as play the normal > reply asking about it, try to reproduce yourself, etc. No! This does not cut it. The bug I reported was against the shipping release at the time. The "cannot reproduce" reply was against the head -- something everyone is told not to consider production -- at the time when the release I reported against was what people were being told to run. You don't get it both ways, and this is an attitude that has to be clobbered. The argument about "we cannot support old releases" is a direct artifact from the people working on -head also trying to tackle most of the bugs; their idea of "old release" is anything prior to last week, and for them that's a reasonable argument. Again, we come back to category 1.5. We need to cultivate people with smarts who can address bugs in production releases. We also need to cultivate the concept of MFS: merge from stable. There is nothing heretical about transplanting fixes from 6.x to 7.x. I firmly believe the reason we have very few 1.5s is because the 1s won't have anything to do with anything outside of today's p4 or cvs. That has to stop. > Guess what I mean is, damn, that's a huge project. :( No, the huge project is implementing a new bug tracking system. What we have can't even accommodate MIME for cryin' out loud. Searching is painful. Task assignment (and tracking) is all-or-nothing. As much as I loathe SQL, I'm ready to admit that we need something new built upon a relational database if we're going to move forward with any hope of keeping up (and doing a good job). --lyndon P.S. I've made liberal use of the 'royal we' above. I have no affiliation with the FreeBSD project, other than having been a (mostly :-) happy customer since the 1.5 release.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?100081FA-6B1E-43A5-A447-A9ABFE5A44E6>