>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> --VbJkn9YxBvnuCH5J Content-Type: text/plain;
Anthony> charset=us-ascii Content-Disposition: inline
Anthony> Content-Transfer-Encoding: quoted-printable
Anthony> On Fri, Apr 13, 2001 at 01:11:31PM -0400, Sam Hartman
Anthony> wrote:
>> I believe it is consistent with that text for me as a
>> maintainer to close a normal bug opened against my package
>> because I violate a should guideline explaining why I had a
>> good reason for doing what I d=
Anthony> id. While generally a bug, it might not be a bug in my
Anthony> case.
Anthony> Sure. *Everything* in policy is just a guideline, and
Anthony> there can always be special cases. That's why we have
Anthony> maintainers with good judgement.
No, actually, I don't believe the guidelines that are MUST should be
up to the maintainer's judgement. I don't believe it's ever
appropriate for me as a maintainer to say that I want to violate the
guidelines in section 2.1 regarding package copyright. Yes, I would
reach this conclusion every time I considered violating the guideline
and applied common sense. However, I believe it is likely the
consensus of this list that no one should ever violate these
guidelines. My intent in this paragraph is simply to establish that
there exists a class of guideline that a maintainer does not have the
freedom to violate and that we can agree ahead of time on at least one
member of this class.
>> My problems with the current policy are
that it's not clear it >> acknowledges the existence of the class of
guidelines that have >> exceptions other than not being implemented by
enough packages.
Anthony> If you don't have any common sense or good judgement,
Anthony> please go away.
I believe I do, so I choose not to go away at this point.
Anthony> If you do: use it. It's almost always clear whether a
Anthony> policy violation is a mistake, or if it's deliberate and
Anthony> desirable. If it's not, it's probably worth talking about
Anthony> it, and either updating policy to mention the exception,
Anthony> or noting it in README.Debian, or doing otherwise.
Agreed, but not relevant to my point. I asserted that it was not
clear to me that policy acknowledged that class of guidelines, not
that I as a maintainer don't acknowledge that class of guidelines.
There are people who go away reading the definition of should in
policy and believing that the only difference between should and must
is the typical severity of the bug. I think this is a bug in
policy--and just because I as a maintainer can understand what was
really meant doesn't mean that cleaning up the wording isn't a good
idea.
>> Also, it's not clear to me that I have recourse as a user if a
>> package is violating a should in a way that creates a
>> significant problem for users of that packages.=20
Anthony> File an important bug if something about a package causes
Anthony> significant problems for significant numbers of
Anthony> users. Submit a patch as well. Talk to the maintainer and
Anthony> make sure your patch doesn't have any ill effects for
Anthony> others.
I'm going to try and file a good bug report regardless of the severity
of the bug. I think though that this points out one of our major
disagreements : I believe that violating a SHOULD guideline (in the
RFC sense) without good reason ought to be an RC issue, just as
violating a must guideline.
Anthony> This is free software: you don't need threats and sticks
Anthony> to get things done.
This is a social system. People are motivated in part by
consequences. I suspect that if you looked at the social impact of
your testing scripts, you would find that serious and higher priority
bugs are fixed much sooner in actievly maintained packages than
previously. Since I consider many unreasonable violations of should
guidelines to be as serious as violations of must guidelines, I'd like
to extend the same social insentive to those cases.
Anthony> You're all insane, btw.
By insane, I assume roughly that you're saying we're being
unreasonable--trying to take policy in a direction that will create
guidelines so unreasonable that they are not followed, significantly
damaging the distribution by throwing away packages unreasonably,
driving away maintainers, etc. I really don't thinkthis is the case. I'm
basically asking us as debian-policy to do more work to help our
maintainers and to a certain extent users. I'm asking us to make
clear when we've decided a guideline is in the non-empty class of
guidelines that maintainers don't have the freedom to violate. I've
asked us to clarify when we'd like to change guidelines from a should
in the must in the future, again giving maintainers more information.
I've also suggested that there are cases where violating should
guidelines ought to be considered RC; I need to think more to decide
whether I'm insane for suggesting this. I've tried to explain how I
believe this would be useful to me as a maintainer. Others have
pointed to the IETF and shown how these types of distinctions help in
protocol design, which is a very similar field to package policy.
I think I've established fairly clearly that there are real tradeoffs
here. It might turn out that an insufficient number of maintainers
would find this additional information useful or that the cost of
communicating/maintaining this information would be too high. But I
certainly don't see for example how these proposals are increasing the
disconnect between policy and practice. Certainly, some of the
examples in this discussion (manpages a must) have been close to
insane, but I don't think the proposals are unreasonable to consider,
even if we decide that tradeoffs we identify don't justify a change.
