Re: what needs to be policy?
Manoj Srivastava wrote:
> FUD. If you are changing things in a incompatible fashion and
> breaking other packages and policy, I sure hope t put additional
> obstacles in your path. In fact, this is a prime argument for
> putting sub policies under the policy change mechanism.
You're ingoring the possibility that things may be changed in an
incompatible way but with a structure in place to preserve backwards
compatability. You're assumming that a package maintainer can not make any
large changes in the interface to their package after it becomes widly used
in debian, and this is flat out untrue.
Example: If the format of menu files changes, the menu maintainer should be
free to make the new format the preferred format. They will of course be
required to make the old format still work so they don't break tons of
packages. This isn't hypothetical, this has happened.
If the menu system changed in an incompatable fashion with no upgrade path
it would break tons of packages and bug reports could justifiably be filed
against menu for doing this. So there's no need for it to be policy.
> Either they are debian policy, or they are not. If they are
> not, then one may dismiss bug reports based on not following
> them.
No one may not. There are two valid reasons for a bug report:
1. A package breaks. It does not work, it does not install, whatever. This
is _always_ a bug, it may not be dismissed for any reason.
2. A package is in violation of policy.
There is no need to make something policy if not following that policy would
lead to 1.
--
see shy jo, repeating himself
Reply to: