From owner-freebsd-stable Thu Mar 28 10:44: 2 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 2A49937B400 for ; Thu, 28 Mar 2002 10:43:55 -0800 (PST) Received: from gauss ([65.96.190.131]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020328184354.VTXH2951.rwcrmhc53.attbi.com@gauss> for ; Thu, 28 Mar 2002 18:43:54 +0000 Message-ID: <00c501c1d688$6d0401c0$0200a8c0@gauss> From: "Yeasah Pell" To: References: Subject: the law of the list Date: Thu, 28 Mar 2002 13:34:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > These whiners, who constantly moan for code while never contributing any, > should contribute the code if they want it changed. If you hadn't noticed, many of the changes being discussed involve a large amount of work. It is unreasonable to expect somebody to do the work with the hope that it will be accepted it without first even attempting to discern if it is a good idea. Most importantly, this is not a productive attitude, and will not encourage contribution. But sadly enough, it is a common sentiment on this list. In my mind, steps toward solving a problem like this one go something like this: 1. [ Identify problem ] 2. [ Enumerate possible solutions, and determine cost and impact of them ] 3. [ Choose solution or decide to not implement ] 4. [ Implementation (of course, there can be lots of substeps here) ] It's true that for many simple problems, there is one obvious solution, and one can just go ahead and implement it, and show up on your doorstep tomorrow with code. There are also problems of medium scope for which it is possible for one person to make these decisions quickly in their own mind. This problem does not fall into either of those categories. I'd say we're on step 2. Now all this said, I understand that there is a history of these sorts of discussions coming to a decision point, whereupon no person (including, to the annoyance of everybody on the list, the originator of the thread) steps up to the implementation plate. Avoiding this will not be accomplished by browbeating anybody who appears to fit the profile, though. One possiblity would be to have a system that maintains a pool of problems that don't yet have defined solutions. Maybe file a PR of sorts, and then qualified coders with available time who want to tackle a more architectual problem could fish in that pool. That effectively inserts a step 1.5. [ Choose implementor ] between steps 1 and 2. (It would be nice to at least discuss the problem before doing that, to avoid peppering GNATS with duplicated and/or ill-defined problems.) Create some FreeBSD document that tells people to follow these steps, and "annoying" discussions like this could be avoided. "It is freebsd-stable (or whatever) policy that problems may be discussed if and only if an individual with a proven track record of successful code submissions is signed on to implement a solution if one is chosen. If you wish to discuss something and are not yourself a proven submitter with available time, we suggest you submit a PR with this special format (or whatever), and wait for an appropriate sympathetic individual to take ownership of the problem." Ending "annoying" threads would be a simple matter of pointing the offending people at the document. Perhaps such a document exists! If so, would somebody please point me at it before I annoy the whole of the known FreeBSD world?? :-) >Also I shudder to think that those who customize their systems would >actually learn how to use all the tools available to them to prevent a >makeworld from overwriting or undoing their customizations. :) This is a good point, but it doesn't mean the system must avoid doing anything helpful at all. If you are referring to my suggestion that a default make.conf be made based on a user's installer choices, I concede that it is probably not worth doing (I think I even qualified it as such when I made the suggestion), and it might even lull people into thinking things are easier than they are. The motivation for that suggestion, however, was consistency of the system (especially in the context of other, more important suggestions), not coddling users. >I wish that we could assign a bitch rating to some of these emails. Say a >sliding bitch scale depending on how much code the bitchee has >contributed. Then they could easily be filtered to /dev/null. >Waddayathink? ;) I assume that this is said tongue-in-cheek. Ideas are best judged on the strength of the idea alone, not the credentials of the one who advances it. While relying on credentials serves as a good crutch for those unable to make their own determination of the value of an idea, I believe this list is home to many people able to make that call. I understand that this is an idealistic view of the way things work; in practice, the charisma of the person behind an idea has a lot to do with how well it is received, and their credentials factor into that. But we don't need to go about making this effect any stronger than it already is. /y To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message