On Mon, Apr 16, 2001 at 01:05:02PM -0700, Seth Arnold wrote:
> * Anthony Towns <aj@azure.humbug.org.au> [010416 05:54]:
> > > 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.
> I like Julian's suggestion. It isn't so much to prevent confusion as it
> is for convenience of not forcing a context switch when people read RFCs
> versus when people read policy.
This could be achieved just as well by leaving SHOULDs as shoulds,
and changing MUSTs to "should*"'s.
> People manage to work with multiple
> definitions of words all the time -- but we could avoid forcing it, and
> the ensuing discussion, by switching our meanings to match the IETF's.
It's only people on -policy that have to realise that MUSTs and SHOULDs
don't have the rfc meaning, though, afaics. Violating a MUST in an RFC
means your implementation is completely non-conformant. Violating a MUST
in policy means your package is non-conformant. There are exceptional
cases, but...
> If we can simultaneously (a) get the same meanings as the IETF and (b)
> make clear the distinctions between RC and our desires of how packages
> should act by adding a simple asterisk, I am honestly surprised you
> aren't so keen on it, aj. :) I figured you would be the *first* person
> to support Julian's suggestion; you wouldn't have to object every time
> someone introduced MUST to a proposal. :)
No, I'd have to object every tie someone added an * to a word, instead.
It'd probably be fine for a month or two, but so was MUST/SHOULD...
Again, I'm still not seeing a real justification for bothering with the
IETF meanings.
There's a valid cause for confusion here: the difference between MUST
and SHOULD from a "when should we use one, when should we use the other"
persepective hasn't been written down anywhere, or even really understood
in general. It should've been added to policy-process.sgml or at least
discussed, but no one thought of it at the time.
An explanation that makes sense to me, whether it's true or not, is
that people have picked up on when you'd use one or the other in an RFC
context and are using that to fill the void in policy-process; and since
that's not suitable for the current MUST/SHOULD definition, there's a
movement towards changing MUST/SHOULD so it does work, irrespective of
the merits of such a change.
But, aside from making the world seem to make sense to people again,
I'm not seeing what the point would be. Who cares about the RFC-ish
definitions as far as Debian policy and packages are concerned? What
difference does it make to anyone whether we could conceive of reasonable
exceptions when we wrote policy? Why introduce unnecessary complexity?
As an argument against, consider "If people see one set of requirements as
`musts', and another as `shoulds', they might be tempted to just ignore
all the `shoulds' even if there's no good reason to do so. This already
seems to happen to some extent with the RC v non-RC issues."
I also don't think adding a "*" is a particularly great notation. The
RFC people could've done the same thing, defining "must" as "usually
should, but we won't worry if you don't" and "must*" as "always should,
you're not compliant if you don't". There's a reason why they didn't,
even though people mightn't be used to the words being used in the
precise manner they are.
Cheers,
aj
--
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:
pgpSSst5P4ulG.pgp
Description: PGP signature