Re: Bug#30036: debian-policy could include emacs policy
Hi,
>>"Adam" == Adam Di Carlo <apharris@burrito.onshore.com> writes:
Adam> I still don't really understand what is intended by moving
Adam> sub-policies into the policy manual. Is it intended that the Debian
Adam> Policy group take editorial control over the documents?
Yes. If it is important enough to be policy, it needs to come
under more democratic and open control.
Adam> Does the package maintainer lose the ability to change the
Adam> document, unless they are also a policy editor?
The package maintainer for emacsen has no more right than any
other maintainer to change the emacsen policy, IMHO. Secondly, we do
not have policy editors anymore. Thirdly, the policy maintainers have
no more rights than any other maintainer to change the contents of
the policy documents.
Why should one person have control over any dsocument just
because they authored it? You think that the DFSG belongs to Bruce?
Bah.
Adam> More objections:
Adam> Are you really sure you want to ask the menu documenter to do all the
Adam> work to split devel-level policy from user documentation? I admit its
Adam> not a bad idea, but...
No. It shall be done, as in all free software projects, when
someone does it.
Adam> I'm just a little worried about this "manifest destiny" attitude
Adam> toward policy, i.e., ever-increasing scope.
Either it is policy, or it is not. There is no increase in
scope here. There is merely all material that is policy being gathered
under one umbrella, and being put to an open and inclusive amendment
process. No one person has control over policy. No one person should
have control over sub policies. We have been burned often enough by
that.
Adam> I stand by my "middle-of-the-road" position that Policy should instead
Adam> *point* to a number of "blessed sub-policies", i.e., emacsen policy,
Adam> menu policy, etc., telling the user where they may get the
Adam> documents.
And I think the users should be able to get them in one place.
Adam> Maybe even blessing a particular version.... This would absolve the
Adam> policy group of any confusion about who maintains these sub-policies,
Adam> which is often intimately tied to the minute implementation details of
Adam> the package. This also enables maintaniers of subsystems to continue
Adam> to innovate.
I think that any innovations after the aAPI has stabilized had
better be backward compatible, or else they need be ratified by this
group in the frst place. Upgradability is one of the promises we make
to the users.
I think that the relationship between an implementation and
the standard is being blurred by you. Now that a standard has been
put in place, it has grown beyond the original package, and involves
other packages as well. The implementation now has to imlement the
standard, even if the standard was defined as a documentaion of
existing practice.
Innovations can go on by the original author sending the
changes through this group. As I said, once it is policy, the
standard has grown beyond the original package. This should not be a
matter of ego.
Just to prove I am not a power hungry evil schemer (as I was
told I am on #debian in a private conversation), I shall freely
submit the kernel patch and the kernel modules documents (which
define existing policy, and are part of the kernel-package) to the
policy package. As ker5nel-package maintainer, I even undertake
setting the documents to SGML, and removing package specific details
from them. So there.
Adam> The danger of course is that Debian could become hidebound.
Heh, heh.
manoj
--
"Nature is very un-American. Nature never hurries." William George
Jordan
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: