Re: New policy draft available at http://master.debian.org/%7Esrivasta/policy/
Manoj Srivastava writes ("Re: New policy draft available at http://master.debian.org/%7Esrivasta/policy/";):
> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > There are already two important checks and balances: firstly, since
> > they are the DPL's delegate the DPL can fire them if they're doing a
> > bad job.
>
> Hmm. Again, you lean towards a solution concentrating power
> into a few hands. Absolute power corrupts.
Noone is suggesting that anyone have absolute power. However,
historically the project has put a lot of trust in the project leader
in these kinds of areas, and by and large I think all the project
leaders have lived up to that trust. Furthermore, as I say, it's
possible for the developers to overrule anything; if the leader is
doing a bad job they can be recalled.
It is necessary for things to happen well and within reasonable
timescales that not every decision is taken by a formal process.
Formal processes should be there to appoint the people who do make the
decisions, and for disputes.
> Yeah, right. That last time the Ctte was called to do
> anything, they bumbled around for weeks tryingto figure out how they
> could do anything, and then there was nary a peep out of two of five
> members of the ctte
I don't want to get into a detailed argument about the way the
technical committee worked last time, but it doesn't seem to me that
the process was broken, or that it took too long, or that it came up
with a significantly wrong answer.
Are you complaining that it took two or three weeks ? But the current
policy process takes that long too - for every decision, not just
disputed ones - and in the case in point the policy manual itself had
been broken for ages. You can hardly claim it was urgent.
> you are proposing that the ctte be given [...] wide ranging powers.
The committee _already_ has those powers, granted by the constitution.
As an example, let us take the disputed change regarding hardlinks to
dpkg-handled conffiles. If you refuse to change the policy manual,
and Wichert doesn't intervene, then I shall have to appeal the matter
to the technical committee. They will decide the matter on technical
merit and as (as I hope you will agree) since the change in question
is correct, they will rule in my favour. You will then have to change
the policy manual anyway.
As another example: you've been trying to claim that the interface
specs for core packages of various kinds (eg, the dpkg manual) should
be maintained according to the policy process. However, the
constitution says this:
6. Technical committee
6.1. Powers
The Technical Committee may:
1. Decide on any matter of technical policy.
This includes the contents of the technical policy manuals,
developers' reference materials, example packages and the
behaviour of non-experimental package building tools. (In each
case the usual maintainer of the relevant software or
documentation makes decisions initially, however; see 6.3(5).)
So according to the constitution it is perfectly fine for the dpkg
maintainer to write a feature into dpkg and document it; every package
which uses it will have to conform to the interface set by the dpkg
maintainer, and the policy process is not involved at all.
The constitution specifically sets the individual developers of these
core works in charge of resolving these kinds of issues, and
specifically states that the technical committee is the formal dispute
resolution process.
If someone has a problem with what the dpkg maintainer did then they
have to convince the dpkg maintainer, or failing that the technical
committee. If the policy group write something different into the
policy manual and then report a bug against dpkg that it doesn't
follow policy, the dpkg maintainer can just as easily argue that
policy is wrong because it doesn't document reality. The policy group
and the dpkg maintainer become involved in a bug tussle, and the
upshot is that the technical committee will end up having to decide
anyway.
However, there is an obvious problem with the above in the current
state of the world: if people want sensible technical decisions made
they'll have to appeal lots of things to the technical committee. The
technical committee can't say that the process is broken (because
that's not a matter of technical policy), only that the individual
decisions (or lack of them) are wrong. The result will be that many
perfectly straightforward decisions will end up going through what's
supposed to be an appeal process.
That's why I want individuals to be given responsibility for the
contents of the policy manual. It is Wichert, as project leader, who
is responsible for deciding whether the process is correct.
> Frankly, IMHO the ctte should merely be an advisory body for
> the rest of the body; and the decisions really be tasken by other
> mechanisms.
I think then that you should try to get the constitution changed,
because that's not what it says at the moment.
> > (Both of these mechanisms for overriding the policy maintainer(s) are
> > available to the membership via general resolution, too, but I expect
> > that to be unnecessary.)
>
> And untenable, There have been almost no general resolutions,
> and the process is so cumbersome that I suspect there never
> shall be any.
The point about formal dispute resolution processes is that they
define who is supposed to have the final say; I don't think they
should be used routinely.
In most cases people will do the right thing, or can be persuaded.
Only if they can't be persuaded, and pointing out that an appeal to
higher authority (eventually, to the developers en masse) might be
forthcoming doesn't help, is it appropriate to do so.
This is why there have been few general resolutions - it's not because
the process is cumbersome (it's not very), but because it's not been
necessary. There have been a couple of cases where a general
resolution has been `started', but in each case the situation was
resolved without having to go to a vote. Surely this is good ?
Ian.
Reply to: