Re: Conflicts between developers and policy
'From Bill Leach <email@example.com>'
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
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:
> >>"Raul" == Raul Miller <firstname.lastname@example.org> 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.
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@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org