Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> I would be willing to say that we leave determination of the point
>> when following policy is detrimental to the package to the
>> maintainers themselves; so Dale could decide that stripping the
>> binaries is detriental to his package.
Raul> You honestly think this is good enough for new developers? I
Raul> must confess that I'm not really in touch with the sort of
Raul> things they would think.
Of course. You gotta trust people some time. I think we give
folks the benefit of doubt. It is not as if anyone could
silently ignore policy -- they are supposed to file a bug
against policy, which shall submit their ideas to peer review on this
list.
If they are at fault, the bug shall be reassgned to their
package, and they shall have to fix it.
Length of time with Debian is a poor metric of competence.
Raul> So, while I like your general statement that discussion should
Raul> ensue, and I worry about the implications of a statement to the
Raul> effect that a maintainer must announce the policy deviation in
Raul> triplicate. The questions that bother me have to do with flamage
Raul> and harshness directed against people trying their best to help
Raul> us out.
We cannot legislate against flamage, unfortunately. It is my
hope that we give people the benefit of doubt and at least one chance
before jumping on them. It is also my hope that we can refrain from
jumping on people who are, wth the best of intentions, trying to
help.
As to reporting errors in policy, all one has to do is file a
bug report against policy, send a CC to debian-policy mailing list
(asking to be kept on the cc list if one is not subscribed there),
and log the policy volation in the changelog of any package that is
going to ignore policy -- Hmm, this is not so bad, is it? This is not
an event that happens everyday (I hope), so once in a blue moon one
can send a message, wth a CC field, and record it in the changelog,
if any.
Raul> We can't come up with a specific set of tests, no. We can have
Raul> a set of general goals which help focus people's attention on
Raul> the hot spots.
Really? Why can't we insterad examine those hot-spots in the
policy document and try to elimeinate them?
>> In any case, the Policy documents should be amended so that the
>> rest of the maintainers benefit from it as well.
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?
manoj
--
"One lawyer can steal more than a hundred men with guns." The
Godfather
Manoj Srivastava <[EMAIL PROTECTED]> <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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
