Re: what needs to be policy?
Hi,
>>"Joey" == Joey Hess <joey@kitenet.net> writes:
Joey> Manoj Srivastava wrote:
Joey> 1. A package is broken. It does not work, or it does not install, or it
Joey> breaks other packages that depend on it or use it, etc.
Joey> 2. A package is in violation of policy.
>>
>> Of course there is a need, if you want it to be a policy of
>> Debian. Unless it is policy, there is no compelling reason for
>> packages to conform
Joey> You still don't understand me? Now that we have points 1 and 2 clarified:
Joey> There _is_ a compelling reason to conform even if it is not
Joey> policy; because maintainers have an obligation to ensure thier
Joey> packages work, otherwise people will have a legitimate reason
Joey> to file bugs against said packages for violating point #1
Joey> above.
So I do not have to add things to menu? The menu package does
not depend on my packages. If it is never going to be policy, well,
now.
And why should I follow emacsen method of doing things? Heck,
I like my old cobbled ways of doing emacs packages.
No need, indeed.
What if I, the maintainer of an intterface package (menu,
emacsen-common, doc-base, sgml-base) just say this is the way things
work now? There is nothing forcing me to go back to the old way of
doing things (things like this happen)
>> I think we need to create standards that packages follow, so
>> that one may depend on things being a certain way on Debian boxes
>> (like location of the MTA program, and that /var/www means something
>> vis-a-vis the local hosts).
Joey> I have never argued that the fsstnd/fhs should not be in policy. This is
Joey> exactly the type of thing that _must_ be in policy because if it's not we
Joey> have no way to take the violators to task.
/var/www is not a FSSTND thing.
Joey> Policy is a document that all maintainers are supposed to
Joey> become familair with, and that they must work to keep familair
Joey> with as it changes. I see your proposals doubling the size of
Joey> policy, which is going to raise the bar of who can even keep it
Joey> all in their head.
Oh, I don't think this applies at all. It is not as if I can
get away with just knowing policy: I have to know how menu works, and
dww, and the www packages, and dhelp, and doc base and emacsen and
modules and kernel-package and ....
Not only is the volume of things to stdy not reduced, they are
not even distilled enough for me to know what is required of
my package, or how many packages it is required for me to
thumb through before
Joey> I think that your requirement for formalization of everything
Joey> is going to stifle innovation. Going back to the menu package
Joey> example, I have considered hacking in a new, cleaner menu file
Joey> format (while of course retaining back-compatability). If the
Joey> old one were policy, this change would be disallowed until I
Joey> went through the rigamarole of changing policy, if I even
Joey> could.
I think you have no understanding still of what I proposed. I
must not have been very clear.
You can innovate all you want -- as long as the old method in
policy is supported (which you say you support). But you can't report
bugs against packages for using the old method -- until you pass the
new method (after it stabilizes) through policy.
And that is a good thing.
Now that I have taken care of the innovation objection, do you
agree?
Interfaces, after they stabilize, and if they are supposed to
be mandatory, or affect a large number of packages, should still be
made a standard, and modification of standards should not be under
control of any one person.
manoj
--
Whoever does harm to an innocent man, a pure man and a faultless one,
the evil comes back on that fool, like fine dust thrown into the
wind. 125
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: