From owner-freebsd-bugbusters@FreeBSD.ORG Tue Feb 20 16:58:03 2007 Return-Path: X-Original-To: freebsd-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 716B616AE2E for ; Tue, 20 Feb 2007 16:58:03 +0000 (UTC) (envelope-from dbrewer@pixelfish.com) Received: from mail01.vmatrixmail.com (mail01.vmatrixmail.com [216.219.244.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA2513C4A7 for ; Tue, 20 Feb 2007 16:58:03 +0000 (UTC) (envelope-from dbrewer@pixelfish.com) Received: (vmatrix@mail01.vmatrixmail.com) by vmatrixmail.com id S6073294AbXBTQfQ for ; Tue, 20 Feb 2007 08:35:16 -0800 To: freebsd-bugbusters@freebsd.org MIME-Version: 1.0 X-Mailer: Rich Media Mail V4. Vmatrix, (C) 2003 From: "David Brewer" Sender: "David Brewer" Message-Id: Date: Tue, 20 Feb 2007 08:35:16 -0800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Your Recent Trade Show Results X-BeenThere: freebsd-bugbusters@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbrewer@pixelfish.com List-Id: "Coordination of the Problem Report handling effort." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 16:58:03 -0000 Greetings!

Are you happy with your results from Social Linux Expo 2007? Did you have what it takes to make the difference between creating excitement and blending in with the competition, between lots of hot leads and a few hard sells ... between success and failure?

Did you have video?

Why video? Video vividly demonstrates the features and benefits of your products. Video captures the praises of your most enthusiastic customers. Video instills interest, reaction and trust. Video sells.

In just 45 days, PixelFish creates marketing videos that become an integral part of your marketing and sales efforts when it streams from your Web site, launches from multimedia email newsletters, plays from CD video brochures and loops from a DVD at your tradeshow booth.

We are PixelFish. We deliver “The Evolution of Video”. And we guarantee results. Click on the videos to the right to see samples of our work.

Contact us today for a free evaluation of your video marketing needs.

David Brewer
PixelFish, Inc.
800.503.3020 x102
dbrewer@pixelfish.com
http://www.pixelfish.com
RedMan Video
Pentax Video
JEM Video
------------------------------------------------ Unsubscribe to safely remove yourself from this email list, please send email to info@pixelfish.com. Powered by Pixelfish http://www.pixelfish.com From owner-freebsd-bugbusters@FreeBSD.ORG Tue Feb 20 17:10:12 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 A790C16BF54 for ; Tue, 20 Feb 2007 17:10:12 +0000 (UTC) (envelope-from dbrewer@pixelfish.com) Received: from mail01.vmatrixmail.com (mail01.vmatrixmail.com [216.219.244.230]) by mx1.freebsd.org (Postfix) with ESMTP id 1E85C13C4AC for ; Tue, 20 Feb 2007 17:10:12 +0000 (UTC) (envelope-from dbrewer@pixelfish.com) Received: (vmatrix@mail01.vmatrixmail.com) by vmatrixmail.com id S6072897AbXBTQpi for ; Tue, 20 Feb 2007 08:45:38 -0800 To: bugbusters@freebsd.org MIME-Version: 1.0 X-Mailer: Rich Media Mail V4. Vmatrix, (C) 2003 From: "David Brewer" Sender: "David Brewer" Message-Id: Date: Tue, 20 Feb 2007 08:45:38 -0800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Your Recent Trade Show Results X-BeenThere: freebsd-bugbusters@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbrewer@pixelfish.com List-Id: "Coordination of the Problem Report handling effort." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 17:10:12 -0000 Greetings!

Are you happy with your results from Social Linux Expo 2007? Did you have what it takes to make the difference between creating excitement and blending in with the competition, between lots of hot leads and a few hard sells ... between success and failure?

Did you have video?

Why video? Video vividly demonstrates the features and benefits of your products. Video captures the praises of your most enthusiastic customers. Video instills interest, reaction and trust. Video sells.

In just 45 days, PixelFish creates marketing videos that become an integral part of your marketing and sales efforts when it streams from your Web site, launches from multimedia email newsletters, plays from CD video brochures and loops from a DVD at your tradeshow booth.

We are PixelFish. We deliver “The Evolution of Video”. And we guarantee results. Click on the videos to the right to see samples of our work.

Contact us today for a free evaluation of your video marketing needs.

David Brewer
PixelFish, Inc.
800.503.3020 x102
dbrewer@pixelfish.com
http://www.pixelfish.com
RedMan Video
Pentax Video
JEM Video
------------------------------------------------ Unsubscribe to safely remove yourself from this email list, please send email to info@pixelfish.com. Powered by Pixelfish http://www.pixelfish.com From owner-freebsd-bugbusters@FreeBSD.ORG Fri Feb 23 20:26:46 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 1B06116A400 for ; Fri, 23 Feb 2007 20:26:46 +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 D527213C478 for ; Fri, 23 Feb 2007 20:26:45 +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 DD5EE92FD30 for ; Fri, 23 Feb 2007 20:57:32 +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 59881-02 for ; Fri, 23 Feb 2007 20:57:26 +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 11D0792FD22 for ; Fri, 23 Feb 2007 20:57:24 +0100 (CET) Message-ID: <45DF47A1.3020305@elvandar.org> Date: Fri, 23 Feb 2007 20:59:29 +0100 From: Remko Lodder User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: bugbusters@FreeBSD.org 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: Subject: 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: Fri, 23 Feb 2007 20:26:46 -0000 Hello Bugbusters of the FreeBSD team, Currently I am looking into older kern/i386/bin PR tickets that are having patches or are in feedback mode. I am trying to resolve them and get rid of them in general. I can use a little help though, there are specific PR's mentioning specific versions of FreeBSD (4.x for example), which might no longer apply to more recent FreeBSD versions (6.x preferrably). So: I want to ask you guys out there to go hunt for these specific PR's, take out the ones that are no longer relevant , get usefull information for recent FreeBSD versions and get back to us so that we can try to assign the pr to someone :) Apart from that: There are also a lot of PR tickets in the queue's with "Question" material in them, I (and from what I know several others) want to have / keep / maintain GNATS as a PR ticket base (PROBLEM REPORT) instead of a support ticket system. With Maia Mailguard (Where i sometimes try to be active as well); there is a policy that questions are not for the ticketing systems but for the mailinglists. I am asking you guys to identify these tickets and inform us so that we can see what we can do about them and perhaps kill them or get more information :) This was actually just a random message to the bugbusters asking for some help in specific regions that I am processing now :) Thanks! Cheers, Remko -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ From owner-freebsd-bugbusters@FreeBSD.ORG Fri Feb 23 21:07:22 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 020B116A400 for ; Fri, 23 Feb 2007 21:07:22 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DDE3B13C441 for ; Fri, 23 Feb 2007 21:07:21 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 0427960B; Fri, 23 Feb 2007 14:44:37 -0600 (CST) Date: Fri, 23 Feb 2007 14:44:37 -0600 To: Remko Lodder Message-ID: <20070223204437.GA24275@soaustin.net> References: <45DF47A1.3020305@elvandar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45DF47A1.3020305@elvandar.org> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) 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: Fri, 23 Feb 2007 21:07:22 -0000 On Fri, Feb 23, 2007 at 08:59:29PM +0100, Remko Lodder wrote: > Apart from that: There are also a lot of PR tickets in the > queue's with "Question" material in them, I (and from what > I know several others) want to have / keep / maintain GNATS > as a PR ticket base (PROBLEM REPORT) instead of a support > ticket system. I think it's just recognizing reality if we say "only bugs, not support questions". With several thousand PRs in the backlog, we cannot realistically hope to deal with all the actual bug reports. IMHO the best that we can do is to a) try to attract developer attention to the relevant ones as they come in, and b) slowly, in the background, go over the backlog. Given that some bug reports are more useful than others :-) Unfortunately with the slow progress I am making on my current task (changes to portsmon to display visual status of packages) I am not making any progress on the "let's talk about bug reports" issue. mcl From owner-freebsd-bugbusters@FreeBSD.ORG Sat Feb 24 01:32:29 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 BEF3A16A400 for ; Sat, 24 Feb 2007 01:32:29 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from chipmunk.ai.net (axe.ai.net [205.134.161.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8A35413C461 for ; Sat, 24 Feb 2007 01:32:29 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost (net-ix.gw.ai.net [205.134.160.6]) by chipmunk.ai.net (8.13.4/8.13.4) with SMTP id l1O0wCEP010180; Fri, 23 Feb 2007 19:58:12 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Fri, 23 Feb 2007 19:57:50 -0500 From: Tom Rhodes To: Remko Lodder Message-Id: <20070223195750.5e82a475.trhodes@FreeBSD.org> In-Reply-To: <45DF47A1.3020305@elvandar.org> References: <45DF47A1.3020305@elvandar.org> Organization: The FreeBSD Project X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 01:32:29 -0000 On Fri, 23 Feb 2007 20:59:29 +0100 Remko Lodder wrote: > Hello Bugbusters of the FreeBSD team, > > Currently I am looking into older kern/i386/bin PR tickets > that are having patches or are in feedback mode. I am trying > to resolve them and get rid of them in general. > > I can use a little help though, there are specific PR's > mentioning specific versions of FreeBSD (4.x for example), > which might no longer apply to more recent FreeBSD versions > (6.x preferrably). Wow. I've kicked this back and forth since I did the handbook changes. It was then I began thinking of how to deal with this. 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. 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. 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. Or you could go back and start by seeing if the files even exist, if the issue with a merged subsystem or a deprecated subsystem or code, and so on. Guess what I mean is, damn, that's a huge project. :( -- Tom Rhodes From owner-freebsd-bugbusters@FreeBSD.ORG Sat Feb 24 02:34:23 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 A302916A403; Sat, 24 Feb 2007 02:34:23 +0000 (UTC) (envelope-from lyndon+@orthanc.ca) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.freebsd.org (Postfix) with ESMTP id 57B8B13C4B4; Sat, 24 Feb 2007 02:34:23 +0000 (UTC) (envelope-from lyndon+@orthanc.ca) Received: from [192.168.42.2] (d64-180-177-158.bchsia.telus.net [64.180.177.158]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id l1O2Jh6A034826; Fri, 23 Feb 2007 19:19:44 -0700 (MST) (envelope-from lyndon+@orthanc.ca) In-Reply-To: <20070223195750.5e82a475.trhodes@FreeBSD.org> References: <45DF47A1.3020305@elvandar.org> <20070223195750.5e82a475.trhodes@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <100081FA-6B1E-43A5-A447-A9ABFE5A44E6@orthanc.ca> Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Date: Fri, 23 Feb 2007 18:19:42 -0800 To: Tom Rhodes X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_PBL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on orthanc.ca Cc: bugbusters@freebsd.org, Remko Lodder 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 02:34:23 -0000 > 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. From owner-freebsd-bugbusters@FreeBSD.ORG Sat Feb 24 07:44:29 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 5D21916A401 for ; Sat, 24 Feb 2007 07:44:29 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from chipmunk.ai.net (axe.ai.net [205.134.161.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0820013C4AC for ; Sat, 24 Feb 2007 07:44:28 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost (net-ix.gw.ai.net [205.134.160.6]) by chipmunk.ai.net (8.13.4/8.13.4) with SMTP id l1O7iRlx043539; Sat, 24 Feb 2007 02:44:28 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Sat, 24 Feb 2007 02:44:12 -0500 From: Tom Rhodes To: Lyndon Nerenberg 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> Organization: The FreeBSD Project X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 07:44:29 -0000 On Fri, 23 Feb 2007 18:19:42 -0800 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. 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 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 */ From owner-freebsd-bugbusters@FreeBSD.ORG Sat Feb 24 13:49:02 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 84D7716A404 for ; Sat, 24 Feb 2007 13:49:02 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc3-cdif2-0-0-cust64.cdif.cable.ntl.com [81.106.128.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4080513C46B for ; Sat, 24 Feb 2007 13:49:02 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HKwmB-00028q-Eo; Sat, 24 Feb 2007 13:17:23 +0000 Date: Sat, 24 Feb 2007 13:17:23 +0000 From: Ceri Davies To: Remko Lodder Message-ID: <20070224131723.GK2926@submonkey.net> References: <45DF47A1.3020305@elvandar.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="doKZ0ri6bHmN2Q5y" Content-Disposition: inline In-Reply-To: <45DF47A1.3020305@elvandar.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies 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 13:49:02 -0000 --doKZ0ri6bHmN2Q5y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 23, 2007 at 08:59:29PM +0100, Remko Lodder wrote: > Apart from that: There are also a lot of PR tickets in the > queue's with "Question" material in them, I (and from what > I know several others) want to have / keep / maintain GNATS > as a PR ticket base (PROBLEM REPORT) instead of a support > ticket system. With Maia Mailguard (Where i sometimes try > to be active as well); there is a policy that questions are > not for the ticketing systems but for the mailinglists. The FreeBSD Project's policy is also that questions or requests for help do not belong in the PR database. However, if there is a question mark over whether a PR represents a question or a possible bug, please assume the latter until proven otherwise. Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --doKZ0ri6bHmN2Q5y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF4DrjocfcwTS3JF8RAnBBAJ0Q/lJ7X27PIE9a0kbZsJAVp/gqkACfSR+V jGsv6cmLQ4TabvPcNr2CcGA= =KxB5 -----END PGP SIGNATURE----- --doKZ0ri6bHmN2Q5y--