From owner-freebsd-bugbusters@FreeBSD.ORG Sat Feb 24 09:24:40 2007 Return-Path: X-Original-To: bugbusters@freebsd.org Delivered-To: freebsd-bugbusters@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8ECB816A401 for ; Sat, 24 Feb 2007 09:24:40 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from caelis.elvandar.org (caelis.elvandar.org [217.148.169.59]) by mx1.freebsd.org (Postfix) with ESMTP id E84D413C481 for ; Sat, 24 Feb 2007 09:24:39 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from localhost (caelis.elvandar.org [217.148.169.59]) by caelis.elvandar.org (Postfix) with ESMTP id 4183992FD52; Sat, 24 Feb 2007 10:24:39 +0100 (CET) Received: from caelis.elvandar.org ([217.148.169.59]) by localhost (caelis.elvandar.org [217.148.169.59]) (amavisd-new, port 10024) with ESMTP id 55572-10; Sat, 24 Feb 2007 10:24:30 +0100 (CET) Received: from [10.0.2.125] (evilcoder.xs4all.nl [195.64.94.120]) (Authenticated sender: remko@evilcoder.org) by caelis.elvandar.org (Postfix) with ESMTP id A25CE92FCB7; Sat, 24 Feb 2007 10:24:30 +0100 (CET) Message-ID: <45E004D0.6000607@elvandar.org> Date: Sat, 24 Feb 2007 10:26:40 +0100 From: Remko Lodder User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Lyndon Nerenberg References: <45DF47A1.3020305@elvandar.org> <20070223195750.5e82a475.trhodes@FreeBSD.org> <100081FA-6B1E-43A5-A447-A9ABFE5A44E6@orthanc.ca> In-Reply-To: <100081FA-6B1E-43A5-A447-A9ABFE5A44E6@orthanc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 at elvandar.org Cc: bugbusters@freebsd.org Subject: Re: status? X-BeenThere: freebsd-bugbusters@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Coordination of the Problem Report handling effort." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 09:24:40 -0000 Lyndon Nerenberg 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. I am not sure whether you are following the PR tickets and the hunt to make sure something useful can be done with them. We (the bugbusters) are looking over the hedge, not restricted to "reported against 3.2 this no longer lives", if you have seem my feedback requests most of them imply: Is this still a relevant problem on recent FreeBSD versions? Obviously we are not going to fix a 3.2 anymore, but we might be able to resolve this on newer FreeBSD releases. > > 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. Yes and that is needed because there is too little manpower to keep up with the incoming flood of PR's. If all the bugbusters would continuesly try to reproduce things (most likely they dont even have the hardware for this), we would effectively stop working on PR's at all. The submitter most likely has the hardware and most of the time they are happy to see whether the problem is still there on a more recent version of FreeBSD. > > 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. So, I see you going out on the streets, selecting these 1.5 people for us and then you and those 1.5 people you are talking about are going to help us out. Snap out of it, the world isn't as simple as that. If that were the case we would have had a couple of more of those people already. What we need is a group of people monitoring incoming tickets and they dont -have- to be programmers or something, they can just be the first filters and make sure that useful information is included in the tickets at all. Then they can assign it to someone who is active in the region the PR ticket was filed against and try to make sure that a follow-up etc is to be reached. > > 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. Again: You appear to have a can of these people, mind popping it open so that we can use them? It's interesting to see that you are clearly stating that our processes are wrong, but then dont have an opinion on how to solve this. If your statements are that strong you would have come up with a better idea, instead you are being negative and are not producing alternatives. > >> 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 :-) Yes, it seems that people were not interested enough and continued their lives and other code. It happends from time to time, and in a all volunteer project the 'other party' has to live with that. > >> 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. You are clobbered about your specific PR ticket. The idea of Tom is good and is mostly followed by bugbusters, if the reply of a bugbuster isn't good enough for you, then reply, but always remember that we are volunteers trying to help eachother out. There is no way one can claim that something needs to be done right now. You can only make that happen by having paid support from someone who is allround enough to fix these sort of things. > > 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. It is not an artifact, it is real life for us, there is not enough manpower so we are not pretending we can keep supporting older releases. Again the only thing that would resolve this is by having paid support to get these things done. > > 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. I see you are volunteering to help? Please look into the list of open tickets and help us resolve them. We await your feedback on that. > >> 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). My goal was not to discuss our current bugticketing system but to get people to help me and the other bugbusters. > > --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. Now that's at least one happy camper ;) Now, my reply seems a bit grumpy (yes I have stated this before in another post), my idea was overlooked in this email and I only ask for something simple: hunt down the older tickets, are they still relevant? Update the information in the tickets so that we can -try- to resolve them. Thanks. -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */