Re: Must and should again
On Fri, Apr 13, 2001 at 03:20:50PM +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.
>
> Suppose we do. First, what benefit does this provide to the user who
> gets a copy of the new woody release in, say, six months on CD. Can they
> rely on every binary having a manpage? No, because it's not a real "must".
The problem you seem to see is that users will not realise that the
meaning of policy directives has changed. I think this is an issue
that could be fairly easily resolved by explaining the new system in
the policy document itself. Then anyone who actually reads policy
would see that the system has changed.
This will not have any effect on woody; I'm looking at woody+1 to be
realistic.
So let's say we implement this after woody is released. Can a user
rely on every binary in woody+1 having a manpage?
No, but they can't now either because it's only a "should". At
present, lots of binaries don't have manpages. My suggestion would
ensure that by the time woody+1 is released, *almost* every binary
will have a manpage. And by the time woody+2 is released, *every*
binary will (and RC bug if it doesn't). That means that most users
will be significantly better off, even by the time woody+1 is
released.
At present, there is no incentive for maintainers to add missing
manpages; with this system, there would be a very big incentive (your
package update doesn't get into unstable otherwise).
> Second, what happens to, say, security NMUs of packages without manpages?
> Do they get rejected out of hand, because of RC bugs? Or do the security
> team have to write manpages as well as do the fix and release advisories?
> What about NMUs to fix real RC bugs, like the app-defaults thing? Do
> they have to write manpages as well as fix the bugs as well? What about
> maintainers who just want to fix normal bugs promptly? Do I have to, say,
> write manpages for ping6 and traceroute6 and tracepath and tracepath6
> when I make an upload of iputils.dsc to set its Maintainer: to debian-qa?
As I said when discussing this originally:
(1) NMUs may be exempt from these rules for the very reasons you
point out.
(2) Setting its maintainer to packages@qa.debian.org would be an
example of an NMU.
(3) Maintainers who just want to fix normal bugs promptly *will* have
to also make sure that their packages are policy-compliant before
they upload them. Otherwise we are back to the current setup
where policy is ignored by a significant number of maintainers.
> This sort of requirement seems to erect more barriers in the way of
> improving a package's quality, without even offering any assurance that
> the overall quality of packages will particularly improve.
This sort of requirement means that packages will overall tend to be
relatively up-to-date with respect to policy and that policy will have
to be noted by maintainers.
I certainly agree with you that policy compliance makes no assurances
of package quality. That is not the job of policy. Policy's primary
job is to ensure that the packages themselves have a consistent
interface and design, and that they work well together. It does not
particularly try to do anything about the quality of the software
itself.
Either policy is being written by a small group of maintainers sitting
in an ivory tower with nothing better to do with their time, and has
no relevance to the rest of the project, or policy is an important
tool for ensuring that there is a modicum of consistency between
packages. The latter is the reason why Debian is so much better than
many other distros, as Chris Rutter once told a visitor to our stand:
we require packages to comply to quite well defined specs.
Only the truth is that we don't, really. Maintainers who want to
follow policy do, and those who don't, don't. And there's nothing
encouraging them to do so.
Incidentally, the reason that app-defaults required RC bugs and NMUs
was not because policy said so, but because things would badly break
otherwise. That's why policy had to be modified so rapidly on this
point.
> "In order to fix the typo in this bug, you must read the current policy
> document, add a manpage, move to /usr/share/doc, add a symlink from
> /usr/doc, update your description, contact the translation team to make
> sure your package's description and manpages are translated into French,
> German and Japanese, register all your documents with doc-base, register
> your programs with update-menus, ensure lintian doesn't register any
> errors, and then you may upload".
- You must check the current upgrading-checklist to check whether
there's anything which might affect you
- Yes, you must add manpages if necessary. Not hard using tools like
pod2man.
- Yes, you should have long since moved to /usr/share/doc.
- No, we don't require that you contact the translation teams.
- Yes, you should be registering all your stuff with doc-base,
update-menus.
- Yes, you should be checking your packages with lintian before you
upload them.
Note several things:
- these were not all introduced simultaneously
- debhelper helps with several aspects of the above
- lintian was written for a purpose
Are you seriously suggesting that it's OK for maintainers at this
point in time to:
- not bother to check for policy updates on a monthly or bimonthly
basis if they're actively maintaining packages (actually, I think
that a posting of the new upgrading-checklist section to
-devel-announce on release of a new policy version would be a very
good idea)
- not include manpages
- still use /usr/doc
- ignore doc-base and update-mime
- not use lintian or to ignore lintian errors?
> You can't dictate that maintainers will be motivated to fix their packages
> no matter how much you might want them to. It's a mistake to try.
Why can't we? If their package doesn't get in with policy bugs, then
the onus is on them to fix them if they want to upload a new version.
If their package does get in but they just get bugs filed, where's the
incentive to fix them? Look how many times people ask: "why hasn't my
package moved into testing yet?" People *want* their packages to get
into the distribution.
> > 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 seems more like a highly effective way to make maintainers get sick of
> bothering, and leave lots of packages unorphaned but also unmaintained,
> to me.
This is something which should be discussed on -devel. I simply don't
know what the effect would be.
> If you want a truly effective way of doing away with undocumented.7,
> get people to right manpages and submit them to the BTS.
But those maintainers already ignore the BTS. You've indicated that
yourself. Not saying that a combined method won't work: give them the
manpages and don't let their packages into incoming without them.
> Someone has to do the work. The maintainer's already indicated s/he
> isn't that interested in writing manpages by the very fact that s/he
> hasn't written any.
Agreed. But if there were a big incentive....
> If you want manpages as badly as you seem to: *you*
> write them.
No. We're deciding as a project that manpages are a Good Thing and
that binaries have to have them. Are you disagreeing with this?
In your setup, there will never be a time when all packages will have
the required manpages, as there will always be maintainers who can't
be bothered. It is always possible to ask for help, say from -devel
or -qa.
> Recently there's been a flamewar in a newsgroup I like to read about
> welfare and government mandated minimum standards of living. In it, one
> of the participants (who was against it) accused another (who was for,
> obviously) of being in it for the power, the argument was something
> like whoever is in control of ensuring a minimum standard of living
> gets to control both the poor (by being their major source of income)
> and the rich (by controlling most of their income).
>
> There seems to be something similar going on here: policy wonks grabing
> power over maintainers by arbitrarily deciding whether their packages
> are acceptable or not, and using that power to satisfy their own goals
> whether anyone else likes it or not.
Absolutely! I totally agree! The policy cabal rules Debian! Yeah!!
Anyone can join these discussions. Any developer can floor a
proposal. They are not closed. The mailing list is public, archived
and open. But you seem to be suggesting that policy should
effectively not have any power at all. That's absurd.
And if we reach a view on this, I would certainly want it discussed on
-devel (maybe with an announcement about the issue to -devel-announce
to begin with) before even contemplating implementing it. If
necessary, even have a GR.
> Maybe the entire idea of "MUST" is wrong, and -policy can't be trusted
> with fairly and reasonably deciding what's acceptable for release and
> what's not.
<silly>
I think I'm going to upload a command-line tool package which doesn't
have a copyright file, which puts its binaries in /bin, /usr/games and
/usr/bin/X11, which doesn't do the "right thing" in lots of other
ways. But it's OK, because it works, and policy doesn't matter
anyway.
</silly>
> > 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.
>
> "the next day" ?
Turn of phrase meaning "suddenly".
> One day you have a minor bug report against your package.
>
> Three months later, while every other maintainer except you has gone and
> done stuff about it, and a policy proposal listing the packages still
> violating the guideline (yours and a handful of others), and saying why
> consistency in this area is crucially important, passes, the bug gets
> upgraded to serious, and someone offers to NMU for you.
And how many packages *still* use /usr/doc after over 18 months
despite constant discussion on mailing lists and bugs being filed?
> > > 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.
>
> You'll note that phrase: "might need to be modified to bring it up to date".
Yes, absolutely. It's indicative.
> Skipping down, we see:
> > 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.
>
> Skipping further down, you then use this as an indiciation that no one listens
> to policy, and that therefore harsher measures must be undertaken.
And how many packages still don't use /usr/share/doc? Yes, the
Standards-Version is indicative only. But there is plenty of other
evidence that policy is effectively being ignored by many
maintainers.
> [...]
> package doesn't use /usr/share/doc. You'd be wrong. A quick check [0]
> (which would tend towards underestimating) lists 134 such packages, which
> is around half of the 280 packages with standards versions < 3.0.0 in sid.
That's still pretty bad. And there's another 130 packages or so which
have version number >= 3.0.0 which still use /usr/doc.
Your point?
> This group seems quite happy to both make poor assumptions about the
> correctness of other packages (treating standards-version fields as
> more canonical than they are; not wanting to bother checking which
> packages would be affected by new MUSTs in policy), and if -policy
> is holding itself to such a low standard concerning other packages,
> it seems at best hypocritical to demand package maintainers adhere to
> the significantly higher standard that's being proposed.
Agreed. We've made mistakes and have to figure out ways of improving
them. That doesn't mean no-one else should do better.
> > 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:
> > (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
>
> How about we just require them to meet all the MUSTs in current policy,
> whether they've bothered to update the standards-version field or not?
>
> Because we already do that, you'll note.
How to we require it? By filing RC bugs after the maintainer hasn't
done anything about it for 18+ months, followed by NMUs. I'm
proposing that we shift the responsibility towards the maintainer.
This does mean that this group will need to become more responsible,
too.
> > > 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.
>
> http://bugs.debian.org/~wakkerma/bugs
That's enforcing?
> We do enforce this. What we don't do is get in the way of package
> maintainers trying to do their job when it doesn't matter.
I'm saying that respecting policy is *part* of the maintainer's job,
and that we may as well go home if we don't care about that.
> And yes, you are proposing that we do.
No, I'm not.
> > > [...]
> > > 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!).
>
> There are two such packages: lprng and ax25-tools; everything else has a
> valid standards-version. Packages can be buggy, maintainers can make typos,
> it's nothing to get excited about.
Hence the exclamation mark. Lintian would have caught it.
> > 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.
>
> And, equally, old standards-versions are also nothing to get excited
> about. Those numbers just plain aren't meaningful.
So let's encourage people to make them meaningful. When correct,
they're useful.
> > (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.
>
> No, they don't. Further, there are more helpful ways of solving this
> problem than saying "get lost, we don't want your packages" to people
> who aren't subscribed to this list. Restarting Joey Hess's "Policy
> Proposals" sumamries and posting them regularly would help immensely,
> I'd be willing to bet. Restarting the archive wide lintian laboratory
> and using that to find things that need work, would probably help too.
Agreed. But I don't think these are mutually exclusive.
> Lintian alone is a pretty impressive measure at thwarting this.
Only if it's enforced.
> > (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.
>
> This isn't a "problem", it's what you want to have happen prefaced by a
> "not".
Huh? I want it so that when we decide to make it RC, there's very
little work left to do.
> > (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.
>
> It's impossible to maintain high quality packages in an automated fashion.
> Other maintainers aren't robots, you know.
I know. But there are ways of helping the process.
> You'll note that the /usr/share/doc transition was meant to take until
> now, btw, and that we've got 97% of the way there, pretty much exactly
> as hoped. Without doing any coordinated NMUs at all yet.
True.
> > (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.
>
> Demanding that all packages have manpages is not the "right thing". Again,
> this is what you want to have happen, prefaced by a "not".
This is a separate issue; it was an example that's been brought up
here frequently.
> A restatement as a problem might be:
>
> (4) Our distribution isn't very consistent in areas in which it could
> be. For example, many of our packages don't have manpages for all
> their binaries.
>
> This can be addressed by, eg, getting interested volunteers to write
> manpages and submit them to the package maintainers, which is exactly
> what -qa is doing.
Or by ensuring that maintainers do so.
> > (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.)
>
> There is actually language for this, and it was given earlier in this very
> thread.
>
> Some examples from policy:
>
> (with a weakened "should")
Those predate the defined meanings of "must" and "should" as far as I
know. Yuck.
> > Proposal:
>
> It's not really a good idea to make proposals when you're not even
> clear on the problems you're addressing.
>
> > (b) The release manager decides upon a minimum acceptable
> > Standards-Version for each release once (a) has been implemented.
>
> And this goes *precisely* against what you've been saying earlier. The
> minimum acceptable policy for packages to comply with at release is the
> current version of policy. Even a difference of 0.0.0.1 is unacceptable.
I *never* said that. Incidentally, minimum difference would be in the
major patch level.
I'm proposing that we CHANGE THE MEANING OF "MUST" AND "SHOULD".
I'm proposing that we say that all packages have to meed a minumum
version of policy by the time the release happens, using NMUs if
necessary. This does not really happen at present, except when QA
decide to ensure that something happens.
> I'm sure your heart's in the right place with all this, but it seems to
> me your head is obsessed with the idea of abusing the almighty power of
> policy's ability to declare things unreleasable to achieve your goals.
No.
> Is it still not clear why I'm objecting to this every single bloody time
> it comes up? Is it not clear why it concerns me enough to write these
> long turgid essays?
>
> Adding a "MUST" is an *absolute last resort*.
And I'm saying: change the meaning/implication of the word "MUST".
That's why we disagree.
We got it wrong. We used the wrong criteria to define the meaning of
policy.
> If you do it too often, it'll just end up with the RM having to ignore
> policy and go it alone again, just like we always had to when there
> weren't any MUSTs or SHOULDs or important or serious severities. That's
> not something I remotely want.
>
> All this nonsense about "every package uploaded from now *MUST* have a
> manpage because I said so" is far worse though.
Only if it's agreed.
Replace "manpages" by "/usr/share/doc" and you'll have a much better
time understanding what I'm suggesting.
> [0] zcat sid/main/source/Sources.gz |
> awk '/^Package:/ {P=$2} /^Standards-Version:/ {print P, $2}' |
> while read a b; do
> if dpkg --compare-versions $b lt 3.0.0 &&
> zgrep -q "^usr/share/doc.*/$a$" sid/Contents-i386.gz;
> then
> echo "$a $b has usr.share.doc";
> fi;
> done
Pretty inefficient; you'd do better to check for /usr/doc first.
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: