'From Bill Leach <[EMAIL PROTECTED]>' Manoj;
The 'Social Contract' and the 'DFSG' are indeed goal statements. However, they are goal statements of a very imprecise nature. They are not 'working documents' they are rather more like 'lofty ideals'. Ideals that don't necessarily mean precisely the same things to different people EVEN when different people 'enthusiastically pledge their support' and make claims as to how these documents 'spell out' common goals. The various 'technical guidlines' indeed ARE the 'working documents' of the Debian goals. They deal with goal issues that are both explicit and IMPLICIT in the Debian project. I feel that this whole discussion has been fraught with 'missunderstanding'. My personal view of your position for example is that while you have at times made statements that 'sounded to me to be very autocratic' (and I am sure from some of the responses that you have received that they sounded that way to others as well); and yet overall the impression that I have is that you do NOT view the 'guidelines' as an 'inflexible straightjacket' upon developers. I further believe that the basis for your statements is two fold: 1) Never publicly 'belittle' the developer governing documents. [Probably because to do so would tend to give the impression that ignoring the conflicts and problems that such documents have and do attempt to address would ultimately be a disaster for the project] 2) 'Regulations' in the governing documents ARE NOT absolutes and just as is true for any other aspect of the project, they are subject to revision and (hopefully), improvement. a. It is highly unlikely that ANY one developer will know ALL of the reasons why a particular decision was made. b. It is even less likely that a single developer will know all of the potential impacts that would be caused by a change. c. Only by first rigorously attempting to comply with 'guidlelines', including seeking opinions of other developers and then still finding that existing policy is an impossible or at least unreasonable restriction will any meaningful improvement to the regulating documents occur. Thus, there is a hugh difference between a developer 'violating' policy AND filing a bug against the policy and one that quietly 'just does their own thing'. I personally would suggest that a developer be allowed to 'violate' policy after attempting to follow policy has failed but then be expected to be cooperative in 'hammering out' a new policy as well as changing the package (if required) to comply with the final decision. I doubt that it is a real good idea to become too specific and too detailed in policy. An obvious problem of course is in deciding what is 'too' and what is 'not enough'. It is probably almost as important to be sure that every requirement that is imposed is indeed necessary as well as to ensure that what is required is no more than is necessary. Since much of the policy has evolved, the 'reasons behind the reasons' may never have been addressed. Within a project like Debian there are many 'standards' that have to be set ONLY because chaos would ensue otherwise. My Brit friends continually remind me of the classic example. There is essentially nothing sacred about driving on the 'right' side of the road but evenyone on particular road had better agree on the 'standard'. On Sat, May 02, 1998 at 02:31:04PM -0500, Manoj Srivastava wrote: > Hi, > >>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes: > > Raul> The point is: we've got a wide variety of goals; debian-policy > Raul> is a fleshed-out statement of those goals. > > I think you are taking policy where it should not go. The > Social contract, the DFSG, and the ilk are a statement of our > goals, the constitution represents the rights and duties of the > entities in the project, and the Policy documents list the dos and > don't of designing and implementing debian packages. > > This is the first I have heard of our Policy documents being > goals, and I disagree. > > manoj > -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: "The less you know about computers the more you want Micro$oft!" See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]