Re: Bug#21969: debian-policy: needs clarification about Standards-Version
Manoj Srivastava <email@example.com> wrote:
> Raul> I've mostly agreed with (Buddha and Philip's) statement you
> Raul> quoted a few days ago which talks about what to do when policy
> Raul> doesn't apply properly. I think it has a weakness: in creating
> Raul> the rules for how "debian-policy" is or isn't followed, no
> Raul> policy has been formed about when to go beyond "debian-policy".
> Umm, do you mean the debian-policy mailing list here, or do
> you refer to the set of documents loosely referred to as the "Policy
> Documents"? If the former, then I am quite confused.
The policy manual. The mailing list is a focal point, because that's
where some of the change happens.
> Raul> As you've probably gathered, I'm a little uncomfortable with a
> Raul> blanket statement which claims to convert policy to some rules
> Raul> that always applies to all cases. But if we can come up with a
> Raul> good statement for how we can recognize when the rules don't
> Raul> take us where we want, I can live with that.
> 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.
You honestly think this is good enough for new developers? I must
confess that I'm not really in touch with the sort of things they
Certainly, I think this is an opportunity to (a) better figure out
what we're doing, and (b) let people know.
> At thsi point, one should point this out to the maintainer
> community at large (in case another person is in the same boat and
> has not yet realized that policy is broken), and, since people are
> human and may err, and the maintainer who originally thought the
> policy is flawed may be wrong, and quite possibly the colective
> intellect of the maintainer community may prove helpful.
Yes. But realize there's a whole range of possibilities here,
at one end is "Maintainer just didn't understand our policy" at
the other end is "Maintainer clearly knows how to write better
policy". In the middle is stuff like "policy was ambiguous, and
maintainer thought it made sense bug missed the crucial phrase
that made package technically violate policy."
So, while I like your general statement that discussion should ensue,
and I worry about the implications of a statement to the effect that
a maintainer must announce the policy deviation in triplicate. The
questions that bother me have to do with flamage and harshness directed
against people trying their best to help us out.
> I think that we can't come up with a set of tests a priori to
> determine how to determine when the rules ("Policy Document") are
> flawed, and we trust the judgement of the develoers when they think
> it is time to examine aspects of the Policy Documents.
We can't come up with a specific set of tests, no. We can have a
set of general goals which help focus people's attention on the
> In any case, the Policy documents should be amended so that
> the rest of the maintainers benefit from it as well.
After we figure out how and why, yes. If we make the imperative to
modify policy really strong, and just plain ignore our goals for the
project, I can see this turning into a real mess.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com