Re: Bug#21969: debian-policy: needs clarification about Standards-Version
Manoj Srivastava <email@example.com> wrote:
> 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
The issue isn't trust. The issue is understanding.
> Length of time with Debian is a poor metric of competence.
However, there's a lot of documentation you must digest before
you understand how to do a debian package, and how a debian
system is supposed to work.
And, we're going to get beginning programmers who also want to help us
out. Or, more generally, we'll get people who can offer some incredible
insights in some areas, while being largely unaware of other areas.
> 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
I'd hope for this, too. But, the way this discussion was going, I wasn't
so sure this would remain a possibility.
> 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.
The debian-policy list should get email for all reports filed against
policy. This suggests to me that there should be a maintainer address
for policy, and that it should be set up so debian-policy always gets a
> 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?
Er... I'm didn't mean to imply we can't. Also, I should have said
"We can't come up with a specific set of tests that cover all the
But there's something very different from handling a specific case
(which is good and important) from handling the general case (which
is also good and important).
> >> 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?
The risk is that we'll apply spot fixes which make other problems worse.
Just as software can wind up hacked up and garbled, when people go in
and "fix" problems without really thinking about the design, so can
policy. If you don't know [in simple terms] how the whole thing is
supposed to work, this is a very big risk.
Sometimes people just give up and try to do a complete rewrite, when
the situation gets too bad.
So, anyways, we have the DFSG and the social contract, and we have
FSSTD/FHS, and we probably have around, somewhere, the original goals
for debian. I'm suggesting we need something analogous to DFSG for
technical issues outside the scope of FHS. I used to think that this is
the policy manual. But the more I think about it, the less certain I am.
I'm going to try to draft up an introduction to the policy manual,
that at least touches on the points I think are important.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com