Date: Tue, 16 Mar 1999 18:59:54 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@FreeBSD.ORG (Eivind Eklund) Cc: dcs@newsguy.com, freebsd-chat@FreeBSD.ORG Subject: Re: 1998 Bugs Message-ID: <199903161859.LAA11964@usr06.primenet.com> In-Reply-To: <19990316161941.E4774@bitbox.follo.net> from "Eivind Eklund" at Mar 16, 99 04:19:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I think that would be a good idea. My take on this is that we should > have a team of people that take responsibility for handling PRs, and > that each incoming PR should be assigned to one of the people on the > team. That person has the responsibility for handling the PR *in some > fashion*. Seneca the elder, 4th century BC Roman Stoic philosopher said: "Never substitute activity for action." I think that any strategy that relies on "*making* something happen" will inevitably fail to produce desirable results. > This could be > * To commit a patch > * To track down the correct person for fixing this PR and transferring > the responsibility > * To reply to the person that originally sent the PR, attempting to > get hold of more information > * To decline a suggestion for change I believe that this will be the most frequent result, even when the problem is, in fact, a real bug. This is the typical outcome from any type of crisis management technique. > * To identify this is a correct PR, stamp it with 'correct problem > report', and put it on active status. > > The clue is just that the person does _something_ about the PR, > instead of leaving both the PR and the person sending it high 'n dry, > with no response at all from FreeBSD. I think the original thread had more promise. What is needed is due dilligence in a root cause analysis for the phenomenon. If it is an increase in users, good. If it is an increase in the rate at which bugs occur, then you need to reexamine the process by which code containing bugs is permitted to be committed. Personally, I believe that this will ultimately boil down to a lack of coherent architectural vision, uniformly applied. Whatever the reason, the next stage is a root cause analysis, not a sweeping of PR's under the "not a problem" or "postponed" or "let's assign it to John Dyson, even though he's no longer with the project" rugs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903161859.LAA11964>