Re: Bug#30036: debian-policy could include emacs policy
In article <[🔎] hhiufyp12j.fsf@dres.elam.org>, James LewisMoss <dres@ioa.com> writes:
> Everyone changes policy based on discussion here.
Um, kinda. You have to go though a whole *process*.
Is Manoj proposing that this process be applied to these sub-policies.
No clear answer yet...
Adam> Are you really sure you want to ask the menu documenter to do
Adam> all the work to split devel-level policy from user
Adam> documentation? I admit its not a bad idea, but...
> Don't. Just make a copy in the policy deb.
That would be silly, a bit, since much of the menu sub-policy is
utterly irrelevant qua policy.
Adam> I'm just a little worried about this "manifest destiny" attitude
Adam> toward policy, i.e., ever-increasing scope.
> I don't think that's the intention here. It is more that 'it would
> be nice to be able to install one package and find all the
> documentation that is policy for debian. At the moment we have to
> install at least three (menu, emacsen-common, and policy) and as
> more sub policies are created that will expand. Having all that
> information in one central place (even if contained elsewhere as
> well) is a good thing.
If the idea is that the Policy maintenance practices (i.e., submision,
seconders, etc.) be applied to sub-policies, this is an
ever-increasing sphere of responsiblity for the Policy Group and I can
hardly see how you can deny that.
Adam> I stand by my "middle-of-the-road" position that Policy should
Adam> instead *point* to a number of "blessed sub-policies", i.e.,
> I don't think that that is being argued here. No one (I've seen) is
> saying that the menu policy and the emacsen policy should be
> inserted in the appropriate place in the policy doc. Only that the
> particular files that describe those two policies should be
> contained in the policy _deb_. They don't become a part of the
> policy manual. They just gain a place in the policy package (so
> that when the policy manual points at that policy it is easily found
> in the same package).
You utterly miss the point. What I am questioning is the application
of the current practices for changing policy to these sub-policies.
The same document, another document, the same package, another
package, those are mere details and logistics.
Adam> the package. This also enables maintaniers of subsystems to
Adam> continue to innovate.
> Nothing stops them from doing this. 1) They can change policy be
> arguing here. 2) They can change their package and submit a change
> to policy for that package (when they are done innovating).
> I can't see a common case where the people on policy would reject a
> maintainers change to a sub-policy. There surely will be cases, but
> those would occur anyway (with or without the document being
> included in the policy package).
This seems weak to me. I'm sorry.
Look, I love the new system for maintaining Policy. I lobbied hard
for it. But this system is *barely* able to keep up with the course
of changes for the Packaging Manual and the Debian Policy. You can
try to deny this is true but it is. Bugs are stacking up. Manoj has
done a terrific job -- but why does he have to do it alone? Manoj
went on vacation and nothing got done.
Until the Policy Maintenance teams gets a little wider in depth, and
shows they can turn around a greater volume of changes in the same or
shorter time, I think any discussion of increasing the duties of the
Policy Editors should be shelfed as impracticable.
Adam> The danger of course is that Debian could become hidebound.
> Never. Things change. Why do you think debian-policy exists except
> to change things. Careful, controlled change when things have
> started to slow down, but no control over those quickly changing and
> getting better packages. No one has argued either that as soon as a
> sub policy begins to take shape that it should be taken over by
> policy. Only when it has become stable do we add it to the policy
> package.
Your asking to take control over from the maintainer/author of the
pacakge and documents, and give it to a clearly overworked and
under-coping Policy Editor system.
I agree with your basic tenants:
* all policy should be taken seriously; edits to it should be taken
seriously and reviewed by this group and the Policy change control
system should be applied to it
* all policy should be readable in one, well-defined area.
But I just don't think we're ready for this step. Maybe once all bugs
older than 90 days are dealt with, I'll feel happier.
Is it time to fire the current Policy Editors other than Manoj and
hire new ones? If not, why not?
qI don't mean to be harsh, but I think overextending the current
practices will destroy them, and I don't want that.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: