Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
* Russ Allbery r...@debian.org [111026 00:43]: I think it would be lovely to just use RFC 2119 language or a close adaptation thereof. We're sort of reinventing the wheel here, There is also those previous art called language. I do not think it makes sense at all to switch from the wheel to some cogwheel when still wanting to run on roads. RFC 2119 solves the problem of indicating that these words have specific meanings by putting them in all caps when they're used with specific definitions. That's a totally different way to express things. There are not only some little wording difference. Having to have some all-upercase MUST in every second sentence is not only ugly but would not improve policy at all. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111026132910.ga3...@server.brlink.eu
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
On Wed, 26 Oct 2011 at 09:32:09 +1100, Ben Finney wrote: Charles Plessy ple...@debian.org writes: being a non-native speaker, I sometimes make the error of understanding “may not” as “it is allowed to (one may) not do”, while it rather means “must not”. Like for instance in the recent discussion about dashes in version numbers on debian-mentors. There is a difference in nuance between “may not” versus “must not”. The former is simply the negation of “may”, and I think on that basis it's the correct form to use. (I'm not a Policy maintainer, but I am a native en_GB speaker and an author of specifications using RFC-like conventions...) I think Charles is right that may not is more ambiguous: whether it's correct or not, people do use may not to mean might not, as in it may not work, you'll have to try it and see, whereas I've never seen must not used wrong. RFC 2119 doesn't define a meaning for MAY NOT, presumably because of that ambiguity. The scale from negative to positive in the RFC goes: MUST NOT (= SHALL NOT) SHOULD NOT (= NOT RECOMMENDED) MAY (= OPTIONAL) SHOULD (= RECOMMENDED) MUST (= SHALL) S -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111026181449.gb1...@reptile.pseudorandom.co.uk
Bug#542288: Version numbering: native packages, NMU's, and binary only uploads
On Tue, Oct 25, 2011 at 8:20 PM, Charles Plessy wrote: I believe it should also document the N.N standard for NMUs of non-native packages, since people don't seem inclined to change to +nmu and there's probably no reason to do so. I suppose this isn't a compelling argument, but it's just rather strange that two different schemes/standards are in play here. As a temporary transition, the wording could say non-native nmus can be versioned with either +nmun or n.n with +nmun favored as that will become the standard in the future. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MP_+UsG5zMojO=-ccvz9+fdc9ennuf+qs3twods_sk...@mail.gmail.com
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
On Tue, Oct 25, 2011 at 03:43:26PM -0700, Russ Allbery wrote: I think it would be lovely to just use RFC 2119 language or a close adaptation thereof. We're sort of reinventing the wheel here, and we're not doing a very good job of it in terms of consistency and shared understanding of the terms. RFC 2119 solves the problem of indicating that these words have specific meanings by putting them in all caps when they're used with specific definitions. Doing the conversion in all of Policy would be a ton of work, though. When I was on the policy team, I strongly advocated this and offered to do the work. It was not taken up at the time, but I am still strongly in favour of such a move: many people reading Debian Policy will be familiar with RFCs and their precise use of the RFC 2119 terms; having Debian Policy following the same terminology (ideally also capitalised in the same way) would be fantastic. The amount of work necessary is probably not as great as you fear, though. It will require some judgement calls, but that just highlights the imprecision in places in current policy. One issue which was raised way back when was that a violating a Policy MUST or MUST NOT may not necessarily produce an RC bug - what is considered an RC bug is the preserve of the Release Managers. But that should not stop Policy from using such terms; packages which do not follow such directives are buggy, even if they are temporarily condoned by the RMs. Julian -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111027003316.ga9...@d-and-j.net
Re: Replacing ‘may not’ and ‘shall not’ by ‘must not‘ ?
Le Wed, Oct 26, 2011 at 10:47:41AM +1100, Ben Finney a écrit : Russ Allbery r...@debian.org writes: I think it would be lovely to just use RFC 2119 language or a close adaptation thereof. +1 Doing the conversion in all of Policy would be a ton of work, though. It would be an excellent distraction from more glamorous work :-) Le Thu, Oct 27, 2011 at 01:33:16AM +0100, Julian Gilbey a écrit : When I was on the policy team, I strongly advocated this and offered to do the work. It was not taken up at the time, but I am still strongly in favour of such a move: many people reading Debian Policy will be familiar with RFCs and their precise use of the RFC 2119 terms; having Debian Policy following the same terminology (ideally also capitalised in the same way) would be fantastic. Dear all, I also like the idea very much. I expect the bottleneck to be the peer-reviewing of the changes. How shall we proceed ? One bug per chapter ? I volunteer for Chapter 5, on which I worked previsouly. Chapter 1 is where the explanations will go. Perhaps Ben or Julian can do that one ? While we are at it, I also would like to recommend that in the source SGML document, we try to keep negations (MUST NOT, SHOULD NOT) on the same lines, to facilitate text searchs. Maybe this can be documented as a comment in the source or plainly somewhere in Chapter 1. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111027022015.gb30...@merveille.plessy.net
