Re: Bug#30036: debian-policy could include emacs policy
Hi,
[Sorry for the long delay; real life has a tendency to obtrude]
>>"Ian" == Ian Jackson <leader@debian.org> writes:
Ian> Manoj Srivastava writes ("Re: Bug#30036: debian-policy could include emacs policy"):
Ian> ...
>> Straw man. No one has said anything about dictating how
>> programs work. All that has been proposed is standardization of
>> interfaces between programs that has been left to the whims and
>> fancies of random development.
Ian> The `whims and fancies of random development' - ie, the decisions of
Ian> the relevant maintainer, as informed by whatever discussions etc they
Ian> feel are appropriate - have always been how new design of interfaces
Ian> has been done in the Debian project.
Firstly, just because it has been done from time immemorial is
no reason not to change. Secondly, design is one thisng. Once
the design has been accepted by the project, and several dozen
maintainers have taken the pains to conform to the policy, you, as
an individual, have no right to yank their chain by changing the
underpinnings of policy from under them.
In other words, while the scope of your changes is your
package, fine. When it affects the rest of the project, then I think
that more measured modifications are in order.
Ian> Design by committee - which is what you seem to be proposing to
Ian> replace it - is not a good replacement for the decisions of the people
Ian> who are writing and maintaining the code, and the usual mechanisms for
Ian> influencing them.
Then you have not been listening to me. I said; once design
and prototyping is done, and the interfaces have solidified
into policy; and it begins to affect the project as a whole, then
yes, maintaninence by committee is what I advocate.
You think standards are written by the implementors?
Ian> Suppose the menu maintainer wants to make a change to an interface
Ian> they've defined, of which the policy group claim to have taken
Ian> control. Now suppose that they go ahead and release new code,
Ian> together with the corresponding documentation.
Ian> By what authority do the policy group say that they shouldn't do
Ian> this ?
Oh, legalities now? If need be, I say we vest such authority
in *some* group so that when something has been deemed policy, it is
not whisked away at a whim.
If need be, the project should hold on to the older version of
the package, and the new version is in violation of policy.
I opine that we need something like this to foster greater
cooperation (I certainly would feel less likely to comply with policy
if it were likely to change readily and with little notice).
Note that I am not advocating no change: I am merely
advocating that change in something that has been settled and adopted
as policy be
Ian> The constitution says that developers may:
Ian> 3.1(1) make any technical or nontechnical decision with regard to
Ian> their own work;
Sure. Does that mean I can flaunt policy at will?
Ian> The technical committee could perhaps override their technical
Ian> decision, since the documentation which describes the menu
Ian> system might well count as technical policy. So, the policy
Ian> group would have to ask the technical committee to overrule the
Ian> developer - but they'd have to make a case on the issues, not
Ian> just that the developer wasn't following a procedure that the
Ian> policy group have made up for the development of their own work.
Methinks that is way too much power in the hands of too few
people, and people that have been appointed to power by an
individual, and now hold total control over any additions to this
vaunted group.
Ian> It's one thing for the volunteers who have agreed to maintain the
Ian> policy manuals to decide to give themselves what they see as a purely
Ian> administrative role by adopting the policy procedure; it's quite
Ian> something else for them to insist that other developers need to adopt
Ian> this procedure too !
I think we have grown beyond an old boys club. We need to have
rules in place so that maintainers may cooperate, and when something
is made into policy, one needs be assured that that is indeed a
standard, and not to be changed lightly. If maintainers of packages
that implement policy interfaces are empowered to change and modify
policy at weill, I vertainly am not really going to place much
importance on the demands of policy, and I would not expect anyone
else to either.
manoj
--
Badges? We don't need no stinking badges.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: