[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Must and should: new proposal (was: Re: Must and should again)



On Tue, Apr 17, 2001 at 10:08:24AM +0100, Julian Gilbey wrote:
> On Tue, Apr 17, 2001 at 12:34:49PM +1000, Anthony Towns wrote:
> > 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
> No, it's the readers/users of Policy.  And they are the ones who have
> been getting confused and complaining.  That's why I brought this
> issue up in the first place.

Well, obviously you have to go on what you've seen. Personally, I
don't think I've seen a single user of policy complaining about it or
misinterpreting it. I've seen plenty of people who're trying to write
policy get it wrong, but that's it.

> > 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...
> But then maybe we need a process which says that "A requirement may
> not be made RC without the consent of the Release Manager."  

That would probably work, but I don't see why we can't just ensure that
the assumption "The policy group know what they're doing and have a Clue"
is always valid.

For reference that's the reason I'm still bothering with this thread:
I haven't seen an actual reason for the change you want to make. Be
scientific. Provide a rationale. Provide some evidence.

> > But, aside from making the world seem to make sense to people again,
> I think that's a pretty good reason.

*shrug* It's probably just a difference in philosophy, but I'm more
inclined to blame the people than the world if the one doesn't understand
the other. At any rate, changing something you don't first understand
seems a huge mistake.

> > 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."
> So nothing will change.  And I don't think people generally regard RFC
> SHOULDs as optional: there's got to be a really good reason not to
> follow an RFC SHOULD.

Then why do you think people regard policy shoulds as optional? 

<wavy flashback introduction>
On Fri, Apr 13, 2001 at 12:49:40AM +0100, Julian Gilbey wrote:
> 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.
</wavy>

If anything, the reaction of maintainer's treating policy as having its
RFC meaning would surely have to be overly strict compliance with MUSTs
(ie, thinking that they can never possibly have exceptions), but that
doesn't seem to be happening overly often.

> > I also don't think adding a "*" is a particularly great notation.
> The notation was just a suggestion.  I'm happy for better ones.

Easy: use the word "must" to indicate an RC issue, and the word "should"
to indicate ones that aren't.

It's very difficult to sensibly talk about this when you haven't given any
more reasons for it than "it bothers me" (and possibly unnamed others).

I'm still failing to see why removing the footnote isn't more than enough
to fix any such problems, eg.

Cheers,
aj, who'd rather relying on things that are objectively verifiable, rather
    than oracles like the policy editor or the release manager

-- 
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: pgp9c7RvNbxJV.pgp
Description: PGP signature


Reply to: