Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Here's my (informal) reading of the constitution:
Raul> (1) the developers who maintain debian-policy have complete control
Raul> over what goes into the debian-policy package -- except where that would
Raul> conflict with what other developers are doing.
Since any change in policy documents would affect other
packages, this means that no change can really be made to the policy
document that differs from current policy, or contravenes what any
package out there is doing, if no policy already governs the action.
In other words, the -policy group has not power to really make policy.
Raul> (2) developers, as a group, can set non-technical policy by
Raul> voting.
This is not relevant really, since the policy document
documents technical policy for the most part.
Raul> (3) the technical committee can set technical policy, but are only
Raul> supposed to take action where there's a conflict between developers.
So far, only individual developers can create policy, and call
in on the tech committee to adjudicate if any differences exist. Once they
establish a policy (if there is no contention), or if the committee rules,
policy is created.
Once created, nothing I see here allows policy to be changed.
Raul> (4) developers, as a group, can override the technical committee by
Raul> voting.
Again, Irrelevant.
Raul> Now, looking at chapter 1.1 of the policy document in
Raul> /usr/doc/debian-policy/, it's pretty clear that the document
Raul> describes technical policy (and that details are in the
Raul> packaging manual and ought to be in the systems administrators
Raul> manual). That means to me that the proposal document ought to
Raul> be talking about
Nope. The proposal document is a non-policy informal document
that describes how changes have been made to the technical policy in
recent past.
It is not in its final form, as we refine the process as we
gain experience.
Now, you are contending that the policy group does not have
the power to create policy as it has been doing, under the
constitution. That may well be the case (which is FUBAR, but that is
another story).
If you wish the -policy group to perform as you detail below,
I think nothing would ever get done. We have trouble enough getting
things to happen as the current point, but going through the steps
below effectively means (IMHO) that the current policy document is
set in stone.
Raul> (a) documenting existing practice, and
Raul> (b) getting approval from relevant package developers, and
Raul> (c) getting the technical committee to approve (or disapprove) a
Raul> completed proposal, and
Raul> (d) getting the developers as a whole to overturn a technical committee
Raul> decision.
Raul> Personally, I'd hate to rewrite the proposal document without any
Raul> input from the policy maintainers,
Please create your own, separate document, and see if the
policy group accepts to work in that fashion. We can drop the old
proposal then.
Raul> and likewise, I'd hate to propose a constitutional change to
Raul> match the current proposal document without even more input
Raul> [enough to see that most developers are unhappy with the idea
Raul> that technical decisions are better made by individuals than by
Raul> large groups]. But near as I can see, either the proposal
Raul> document needs to change or the constitution does.
Essentially, the question comes down to this: is a set of
developers (the membership of the set being purely voluntary)
empowered to create technical policy for the project, even if it
affects packages in the project? Do you need to get all the
developers of the package affected to buy into the policy change? If
not, do we need to call in the tech committee all the time (you will,
since no one can please all the people all the time).
Before you answer, ask yourself: is this lumbering, red tape
strewn process actually good for the project? Can the DPL delegate
power to this group to make policy changes that do affect other
packages?
I would agree that we may need to make sure that any change
proposed that affect all (or a large fraction of packages) must
provide for a period of transition, such that not all packages are
made immediately buggy.
But I think that the proposed methodology is too bureaucratic
to actually work.
manoj
--
Showing up is 80% of life. Woody Allen
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
