Re: Conflicts between developers and policy
On 1 May 1998, Manoj Srivastava wrote:
> >>"Dale" == Dale Scheetz <email@example.com> writes:
> Dale> While I agree with much of what you say about the need for
> Dale> policy to be clear, I will continue to urge caution when being
> Dale> dictatorial about policy.
> Dale, I think no one is trying to be dictatorial about
When you say the policy MUST be followed to the letter, I can view that as
nothing less than a dictatorial attitude.
> Phillip said it best; policy is suppposed to be followed
> unless it is wrong. If it is wrong, it is appreciated if you correct
I am a maintainer who chooses not to spend my time in the policy group,
but prefers to spend what little time I have working on my package
responsibilities. One of the things that has bothered me about your
position on this matter, is that you seem to think that maintainers who
don't get involved in the policy discussion are shurking their duties,
while I don't.
> Not everyone has the grasp of the subject as the person pointing
> out the error of policy, so amending policy is really just being
I thought that was what the policy group was there for. I have alwasy
assumed that this kind of work was their responsibility.
As a developer, I use the policy statements to help me decide on
particular issues of packaging. How is it that I am now the responsible
party for fixing a policy that I don't see as broken?
> Why are you fighting this?
The only thing I am fighting is the oppressive attitude that you have been
expressing about the Policy Statement.
> Dale> For example, the "stripped binaries" rule in the policy
> Dale> statement is fine with me. I don't see it as "broken" the way
> Dale> Manoj has suggested, because we have an unwritten policy against
> Dale> delivering broken packages. I see the unwritten policy as having
> Dale> a higher priority than the "stripped binaries" policy as
> Dale> written.
> You know that the stripped binary rule has exceptions. I did
So, why am I responsible for your ignorance?
> Why not put a statement in the policy describing when the rule
> does not hold? (Some would say not correcting policy is elitist and
> hoarding knowledge).
I have no problem with the policy statement containing such statements. In
fact I have argued on several occasions that policy needs to always have
and explanation for its existance, and a priority level for dealing with
conflicting policy statements.
My only problem is when you make it my responsibility to "correct" the
> Dale> While policy only states that the upstream changlog will be
> Dale> named changelog, I see the policy of "least surprise" as
> Dale> allowing me to include a link for ChangeLog so that those who
> Dale> are expecting that will find it. A strict reading of the Policy
> Dale> Statement might not lead others to this conclusion, but I don't
> Dale> see that as broken.
> I think then it is definitely unclear, and an ambiguous policy
> statement is a broken policy statement.
Then fix it, if you think it is broken, and stop chastizing me because we
currently live with a less than perfect Policy Statement. From my point of
view, I follow policy when I deliver a working unstripped binary instead
of a broken stripped one. I also think that I have followed policy when I
add a link that provides ChangeLog for those expecting it. If you don't
think so, then fix it to your satisfaction. I will not object.
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: firstname.lastname@example.org Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org