[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#21969: debian-policy: needs clarification about Standards-Version

>>"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

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


 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: