Re: Must and should again
On Fri, Apr 13, 2001 at 02:22:54AM +1000, Anthony Towns wrote:
> So we no longer accept uploads of packages that don't have manpages for
> all their binaries?
OK, let's take this example then. At the moment it's only a "should".
Why can't we say that, from now on, we will not accept uploads which
fail this?
My suggestion is: change "should" to "must" in policy, and give
packages some time to migrate (eg., one year) before starting to do
NMUs. Then any packages uploaded within the coming year will have to
satisfy this requirement (or have a lintian override if there's a
special reason why they don't need to).
This is probably a highly effective way of doing away with
"undocumented.7" and ensuring that all binaries have proper manpages
without imposing the burden of either large scale NMUs or pulling lots
of packages.
It also means that this problem will not keep reappearing: packages
simply aren't let in in the first place unless they comply.
*** I do think this will also need discussing on -devel if we decide
*** that this would be a good sort of thing to do in general.
> > - we don't file RC bugs on new requirements until we decide that it
> > is necessary and that we are realistically able to fix any packages
> > with the issue outstanding in a reasonable length of time
>
> Indeed. We can do this right now by making them recommendations (should)
> instead of requirements (must), and update them later if it's appropriate.
So one day you have a minor bug report against your package, the next
day it becomes an RC bug report with the threat of your package being
pulled.
In my scenario, once we decide that the requirement is a "must", then
> I have another suggestion. Let's get rid of the "Standards-Version" field
> in debian/control and insist all packages must match current policy.
No and yes.
I think the Standards-Version is good when we look at a package to
determine what the state of policy was when it was last uploaded and
what might need to be modified to bring it up to date. So I wouldn't
want to lose that information.
Yes, I think that all uploaded packages must match current (or at
least almost current) policy.
I don't think that it's reasonable to demand that all packages in the
archive are constantly updated to match current policy, with two
provisos:
(1) There are occasionally issues which need resolving right now; the
app-defaults stuff being one example; these can be dealt with on
a case-by-case basis, and in general, policy should not be
changed in a way which would require such behaviour unless a
transition plan has been worked out in advance
(2) No package should be more than [fill in appropriate time] old
policy-wise, eg., require all packages to have Standards-Version
>= 3.0.0 in woody
> The fact that it's there seems to confuse people into thinking they
> don't have to care about current policy. They do.
But we don't make any attempt to enforce this. I am essentially
proposing that we do.
> [...]
> If you want to make policy apply inconsistently to different packages,
> well, I think that's just stupid, no matter how many times it's proposed.
This is exactly the situation at present. In sid/main, there are
Standards-Versions ranging from 2.1.0 through to 3.5.8 (which is quite
an achievement, really, given current version is only 3.5.2!). Out of
approximately 4000 packages, there are close to 300 source packages
with version < 3.0.0 and over 1000 (that's a quarter) with version
less than 3.1.0.
> It'd help if you'd come up with a clear statement of what you'd like to
> achieve, independent of your preferred solution. "Distinguishing between
> guidelines that will get a package thrown out of the distribution and
> guidelines that won't" is the problem MUST/SHOULD/MAY is designed to
> solve, eg.
Problems:
(1) Many maintainers ignore policy changes and don't apply them to
their packages. The above statistics give some indication of the
extent of this problem.
(2) We don't enforce policy dictates except by filing RC bugs at a
very late stage in the process, once we've decided that the
requirement should be an absolute.
(3) The above two points mean that it is hard to maintain a high
quality of packages in any automated fashion, and that a large
burden is put on a small number of developers who try to fix the
problems thereby caused, for example the /usr/doc ->
/usr/share/doc transition is still not complete.
(4) It also means that we are often afraid to "do the right thing"
and demand that packages satisfy certain criteria (all binaries
to have manpages) because too many packages will then receive RC
bugs, even though we should demand this of all packages and it
really isn't an RC issue.
(5) There is only language in policy for "this is an RC requirement"
and "this is a requirement, but not RC". Both indicate bugs if
there is a failure to comply. There is no language for: "except
in unusual circumstances, you must do this", which would not
necessarily indicate a bug for lack of compliance. (For example,
the update-rc.d binary in file-rc need not have a manpage, as it
depends on sysvinit which does. So maybe the manpage requirement
really ought to be a "should" or needs to explicitly exclude this
type of case.)
Proposal:
(a) Package uploads into unstable must comply with the latest version
of policy (or be no more than, say, one month out of date).
Suggested implementation: lintian could be used to do this, with
a strict check on the Standards-Version. It would probably be a
slightly rough ride to begin with, but worth it in the long term.
We'd need to figure out what to do with lintian overrides though:
perhaps "must"s could not be overridden but "should"s could be?
(b) The release manager decides upon a minimum acceptable
Standards-Version for each release once (a) has been implemented.
Most packages will automatically satisfy this requirement due to
the enforcement in (a), especially if the minimum version is no
later that that of the previous released version; I would guess
that >90% of packages are uploaded at least once per year.
(c) Urgent requirements could be dealt with using the current RC bug
method after being discussed on -policy.
Then, as a *corollary* of the above, "must" and "should" would need to
change their meanings, as we would have a different way of determining
which policy bugs are RC, given in (b).
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Reply to: