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.
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.
(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*.
(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.
> - 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?
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]
> - 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:
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.
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).
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.
> - 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).
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.
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.
Trying to document all the possible exceptions in these cases seems like
a waste of time, in most 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]
Note that I don't have anything against this; I just don't see any reason
for it.
> - it's clear what one ought to do to create a "good" Debian package
I'm not seeing why you'd think isn't already clear: you follow every
policy guideline that makes sense to you, then double check that your
reasons for not following all the others makes sense. Doesn't matter
whether they're RC or not, or "compulsory" or not.
Cheers,
aj
[0] "confused" + "equated" = "conflated". It's not the real deriviation, but
I like it better. :)
[1] "If we don't know what the copyright is, then we might be violating
copyright law by distributing it." or "If packages don't specify
their dependencies properly, then user's'll end up with broken
systems when they use apt-get or dselect" or "Having all packages
use the same general filesystem layout makes it orders of magnitude
easier for the sysadmin to cope"
[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.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpffuNebOQFJ.pgp
Description: PGP signature