Date: Sat, 24 Feb 2007 02:44:12 -0500 From: Tom Rhodes <trhodes@FreeBSD.org> To: Lyndon Nerenberg <lyndon+@orthanc.ca> Cc: bugbusters@FreeBSD.org Subject: Re: status? Message-ID: <20070224024412.6b906bfd.trhodes@FreeBSD.org> In-Reply-To: <100081FA-6B1E-43A5-A447-A9ABFE5A44E6@orthanc.ca> References: <45DF47A1.3020305@elvandar.org> <20070223195750.5e82a475.trhodes@FreeBSD.org> <100081FA-6B1E-43A5-A447-A9ABFE5A44E6@orthanc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 23 Feb 2007 18:19:42 -0800 Lyndon Nerenberg <lyndon+@orthanc.ca> wrote: > > 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. Personally, I think it would be a good starting point for any type of bug investigation considering that if the code is gone, the associated bug is probably gone as well. > > 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. These two broad ranges don't cover individuals who lack any programming knowledge and want to help out with things like documentation and bug hunting. Bug hunting, here, I should actually say testing. > > 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. I'm not sure I agree here. Some people want to have direct access and others don't. It is very possible someone who spends a decent amount of time doing nothing but bug fixing could burn out quickly, but there are other aspects to this. Poor time management, not enough sleep, lack of time off. If you worked all month long without a single day off, would you refrain from becoming a bit irritable? I couldn't. > > > 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 :-) Interesting PR there. Wonder why it hasn't been committed though. > > > 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. So, we commit untested code? I'd feel more comfortable not introducing new bugs. I agree in some cases you can just look and say "oh yea, that is wrong, we can fix it" but in others it needs to be tested in some way. > > 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. A lot of people MFC, some just sooner than others. I'll agree that, to some extent mind you, we should support old releases. But there has to be a cut off period. > > 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. What is wrong with getting a large project in p4 to a useful point without spamming the entire tree with partially implemented ideas? What if we start a project that sounds promising and learn it isn't useful? Backing out several months worth of changes would really suck. Outside development is happening, using p4 is just sometimes easier. > > > 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). That discussion is nothing more than beating a dead horse, if you'll pardon the expression. It's been hashed and rehashed many times over the years. My *personal* opinion is that there is no need to change the tools. I'm picky, but the tools work fine for me. > > --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. > -- Tom Rhodes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070224024412.6b906bfd.trhodes>