Re: Bug#21969: debian-policy: needs clarification about Standards-Version
Hi,
>>"Raul" == Raul Miller <rdm@test.legislate.com> writes:
Raul> The issue isn't trust. The issue is understanding.
I think I am willing to give new maintainers the benfit of
doubt as to whether they can excercise enough judgment to know if
they understand a subject well enough to go and try to amend
policy. In a sense, then, this is a kind of trust, a trust that the
new guys are not off the wall and won't pepper the plicy list with
frivoulous amendment attempts.
>> Length of time with Debian is a poor metric of competence.
Raul> True.
Raul> However, there's a lot of documentation you must digest before
Raul> you understand how to do a debian package, and how a debian
Raul> system is supposed to work.
Raul> And, we're going to get beginning programmers who also want to
Raul> help us out. Or, more generally, we'll get people who can offer
Raul> some incredible insights in some areas, while being largely
Raul> unaware of other areas.
I fail to see the problem. They file a bug report. People on
the list discuss it, and let the new maintainer know the
fallacy. Possibly a rationale is added to the policy documents so it
is easier to understand.
I think that objecting to the statement that Budha Buck made
on these grounds is being overtly paranoid, and slightly insulting to
new maintainers.
Raul> After we figure out how and why, yes. If we make the imperative
Raul> to modify policy really strong, and just plain ignore our goals
Raul> for the project, I can see this turning into a real mess.
>> What do you mean by that? How can having a policy that conforms to
>> correct behaviour be against the goals of the project?
Raul> The risk is that we'll apply spot fixes which make other
Raul> problems worse.
I think you do us a disservice here. And, anyway, there is no
escaping this. We can alsways make decisions that are bad in the long
run. Unless you have a reliable crystal ball, this is impossible to
avoid.
Raul> Just as software can wind up hacked up and garbled, when people
Raul> go in and "fix" problems without really thinking about the
Raul> design, so can policy. If you don't know [in simple terms] how
Raul> the whole thing is supposed to work, this is a very big risk.
You suddenly seem to be arguing that policy never be amended
since we may just be screwing it up. If we can't depend on the wisdom
of the people on the mailing list, or in the project in general, we
may as well give up on systems integration and take up knitting.
Raul> I'm going to try to draft up an introduction to the policy
Raul> manual, that at least touches on the points I think are
Raul> important.
I think that should be a separate document, to be ratified
under the proposals of the constitution. Policy should remain a set
of technical dos and don't. Anything other than that should be
considered for removal from the policy.
Anything else shall be overloading the purpose of the policy
documents. Maybe we should rename the current set "The *TECHNICAL*
policy documents", and let non-technical policy be drafted and
ratified.
manoj
--
If builders built buildings the way programmers wrote programs, then
the first woodpecker that came along would destroy
civilization. Gerald Weinberg (sysop's note: bull)
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: