[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Policy about policy



In the wake of the 3.0.0.0 release of debian policy, I've been studying
the policy process.  In particular, I've been looking at the debian
constitution, and the contents of the 3.0.1.1 debian-policy package.

Originally, I was going to make a formal proposal to update debian
policy.   However according to /usr/doc/debian-policy/proposal.html/
(or http://master.debian.org/~srivasta/policy/), a vote was supposed to
have been carried out last year -- but there's no indication that the
document was ever accepted.

If it's been accepted as debian policy (not technical policy, obviously)
then I think this document should be updated to reflect this status.

Also, I think the debian constitution should be included in
/usr/doc/debian-policy/.  As near as I can tell, it's not included in any
other package -- and it's at least as important as the proposal document.

Finally, I'd like to see proposal document updated to reflect what the
constitution has to say about policy.

Here's my (informal) reading of the constitution:

(1) the developers who maintain debian-policy have complete control
over what goes into the debian-policy package -- except where that would
conflict with what other developers are doing.
(2) developers, as a group, can set non-technical policy by voting.
(3) the technical committee can set technical policy, but are only
supposed to take action where there's a conflict between developers.
(4) developers, as a group, can override the technical committee by
voting.

Now, looking at chapter 1.1 of the policy document in
/usr/doc/debian-policy/, it's pretty clear that the document describes
technical policy (and that details are in the packaging manual and ought
to be in the systems administrators manual).  That means to me that
the proposal document ought to be talking about 
(a) documenting existing practice, and
(b) getting approval from relevant package developers, and
(c) getting the technical committee to approve (or disapprove) a
completed proposal, and
(d) getting the developers as a whole to overturn a technical committee
decision.

Of course, these are alternatives, at least to some degree -- I wouldn't
expect most policy proposals to have to go through all these stages.
However, I think each of these alternatives is important.

Personally, I'd hate to rewrite the proposal document without any
input from the policy maintainers, and likewise, I'd hate to propose a
constitutional change to match the current proposal document without
even more input [enough to see that most developers are unhappy with
the idea that technical decisions are better made by individuals than
by large groups].  But near as I can see, either the proposal document
needs to change or the constitution does.

Then again, I've been wrong many times in the past, and expect to be
wrong in the future -- and perhaps I'm wrong here.

Comments?

-- 
Raul


Reply to: