Re: Must and should: new proposal (was: Re: Must and should again)
On Mon, Apr 16, 2001 at 10:38:39PM +1000, Anthony Towns wrote:
> On Mon, Apr 16, 2001 at 10:49:14AM +0100, Julian Gilbey wrote:
> > On Mon, Apr 16, 2001 at 02:16:24AM +0100, Julian Gilbey wrote:
> > > I guess there are two conflicting desires here:
> > > (1) The Acting Release Manager's desire to have it clear what
> > > constitutes an RC bug.
> > > (2) Developers' desires to know what "must" be done in all cases and
> > > what "ought" to be done (but there may be exceptions), and what is
> > > currently a "desirable thing" but is likely to one day become an
> > > RC requirement.
>
> I don't think they're conflicting, I think they're just being conflated
> [0], which is causing huge amounts of confusion.
Agreed, the word "conflicting" is wrong.
> I can think of three different things that people want to get out of
> policy, that it hasn't given in the past.
>
> (1) I want release-critical and non-release-critical issues
> intelligently differentiated. Not having a copyright
> versus not having a manpage is an obvious example. Having
> app-defaults in the wrong place versus having fonts and
> binaries in the one package is probably another. It'd be
> helpful if the RC issues (beyond having security problems,
> or just plain not working) were written down somewhere so I
> could be consistent in applying them, and it'd probably be
> better if there was a reasonable process for updating them,
> rather than just at the release manager's whim.
Agreed; point (1) above.
> (2) People want some indication of where policy's going to go
> in the future. For things like "You don't have to move to
> /usr/share/doc for potato, but it's easy and you will have
> to for woody...", say. People also want some indication of
> what they actually have to do *now*.
Agreed; this is a good thing for footnotes.
> (3) People also seem to want to be able to say that some policy
> guidelines don't have any exceptions, and seem to think this
> is what MUST/SHOULD/MAY is about, because that's how it works
> in the RFCs.
Agreed. My point (2) above.
> > - Anthony's already indicated that he's not particularly bothered if
> > we change the specific words used to indicate RC and non-RC, but he
> > really wants the RC/non-RC distinction to remain in policy
>
> I'd like it in policy, but only if the -policy group can treat it
> intelligently. I'd originally had no doubts about this at all; at the
> moment though, I'm still pretty concerned. How come the "Errors which
> occur during the execution of a script" should's became must's?
Absolutely. I have no doubt that we can. As far as the errors which
crept in go, I don't know what happened, but I will dig up the bug
report when I have a moment and go through it again to correct things
which were missed. I have no doubt that it was a genuine mistake
rather than anything more.
> There also needs to be much clearer guidelines about when MUST's may be
> added, and they need to be fairly thorough. Working out how many packages
> are affected, and ensuring that's a fairly small number would be a start.
> An explanation of why it's better to throw such packages away rather than
> keep them would be helpful too. [1]
Agree, modulo s/MUST's/RC issues/ or something similar. I would be
happy for you to suggest such guidelines, as you have made it clear
that you regard this as the responsibility of the ftpmasters and
release manager, and not of the policy group.
> > - Others have suggested that they would prefer to have MUST and SHOULD
> > retaining their IETF meanings
>
> I'm not really convinced this is particularly worthwhile. Some examples:
OK. As long as you're not particularly bothered and don't have to do
the work, there are enough people who have mailed -policy being
confused about this that I think it's probably worthwhile.
> Issue Release critical? Must always be followed?
> ----- ----------------- ------------------------
> 1. Missing copyright Yes Yes
> 2. Library w/o shlib Yes No
> 3. Missing manpage No Yes (?)
> 4. Use alternatives No No
>
> I'm not sure whether you want to say that "all programs must have manpages"
> in the RFC sense or not. I presume you do.
It wasn't my original example; I don't know if there will be
exceptions, but it would seem to be sensible, even if the manpage only
refers to the location of the main documentation.
> If you have a package that violates issue 1 or 2, you file a serious bug
> about it. If you have a package that violates 3 or 4, you file a normal
> bug about it. (Note that 3 is specifically *not* a release critical issue,
> and thus doesn't justify a higher severity).
Absolutely agree (although I'm not quite sure what you mean by the
"library w/o shlib" example).
> OTOH, you might have a package that violates a guideline for a good
> reason, in which case it's not a bug against the package, but rather a
> bug against policy, for, well, being wrong. But that also doesn't depend
> on whether we thought that issue "must always be followed" or not: we
> can miss a special case even if we're aware of their general existance,
> and we can certainly miss a special case if we didn't think there were
> any in the first place.
Absolutely; in such a case, there is already a clear procedure: file a
bug report against policy. Then policy can choose to do one of
several things: (1) explain to the bug-reported how they've got it
wrong and how to fix the package in question; (2) add an exception to
the rule in policy; or (3) change an (IETF) MUST into an (IETF)
SHOULD. But this will have no effect on whether or not the package is
allowed in (assuming it's an RC issue), as if the package is doing the
right thing, it will be allowed in, and if not, it won't.
> > - So how about giving MUST and SHOULD their IETF meanings, allowing
> > policy to state how things *ought* to be done to comply, and
> > appending an asterisk to ones which are regarded as RC. So
> > everyone's needs are met: developers know what things really ought
> > to be done to create a good package, and it's also clear which
> > things are and are not considered RC. As *examples*:
> > Packages with app-defaults MUST* install them in ...
> > Packages MUST install their documentation in /usr/share/doc ...
> > Packages SHOULD comply with the FHS ...
> > Every user-level binary MUST have a manpage ...
>
> FHS compliance is a release-critical issue. Or, at least, FHS
> compatibility is. You could phrase it as something like:
>
> Packages MUST* be compatible with the FHS.
> Packages SHOULD* comply with the FHS.
>
> It's not clear how you'd indicate that the only exceptions to full
> FHS compliance that're okay are the ones listed in policy (namely,
> the /usr/doc stuff).
That's a straightforward issue however we resolve this one. Something
like:
Packages MUST* be compatible with the FHS and packages SHOULD*
comply with the FHS, with the following exceptions: packages MUST
now be placing their documentation in /usr/share/doc with symlinks
from /usr/doc as described below.
or perhaps clearer:
Packages MUST* be compatible with the FHS and packages SHOULD*
comply with the FHS, with the following exception: it is not an RC
bug for packages to still place their documentation in /usr/doc.
<footnote>It soon will be</footnote>
> It's also not clear how you'd cope with things like /var/cvs, which is
> okay since there's nothing better we can do, but which is in violation
> of the FHS.
Add it to the list of recognised exceptions. But this is an issue
regardless of whether we use the current "MUST" or the proposed
"MUST*", so is just likely to lead us off-topic. Or maybe this is one
example where a SHOULD* would be better than a MUST*; then we don't
need to list out the exceptions.
> There are different levels of excuses allowed here too. For example,
> "Upstream doesn't think a shared library is a good idea" is probably
> enough of a reason not to have a shared library; whereas "Upstream puts
> this program in /opt/foo/bin/foo" *isn't* a good enough reason to do
> likewise. This is in spite of them both being SHOULD*'s, afaics.
Agreed. Read RFC 2119: you'd better have a really good reason for
violating a SHOULD*. What constitutes a "really good reason" has
nothing really to do with this discussion; I trust individual package
maintainers and the ftpmasters to know the answer in individual cases.
> Trying to document all the possible exceptions in these cases seems like
> a waste of time, in most cases.
Absolutely! So use an IETF "SHOULD" or "SHOULD*" in such cases.
> > Does that possibility satisfy everyone:
> > - MUST and SHOULD change to the universally-recognised IETF meanings
>
> It's still not clear why this would be a Good Thing.
>
> The only real reason I've seen is that it's confusing people (and then,
> it's not apparently confusing maintainers per se, just policy people who
> think about it too much). That could be solved just as well by changing
> must to "HAVE TO" and should to "OUGHT TO" (and may to "MIGHT LIKE TO")
> or something. [2]
No, it's confused several people who are not "policy people". They
were the ones who brought this issue up in various ways several times
in the past few months. Just because you don't have a problem doesn't
mean that other people don't.
Yes, we could avoid the IETF words, but they're actually quite useful
with the IETF meanings, and are somewhat orthogonal to the question of
RC-ness as you have shown above.
So I think it would be nice to incorporate both desires in a nice way,
hence this suggestion.
> Note that I don't have anything against this; I just don't see any reason
> for it.
Wonderful! I think we've now found a compromise.
Thanks!
> [2] Personally, though, I think we could equally well end the confusion by
> getting rid of the "see rfc<..>" footnote and stop talking about
> the RFC definitions on this list.
The newly uploaded version clarifies this point.
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: