Must and should: new proposal (was: Re: Must and should again)
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.
A suggestion and a thought. Suggestion first:
- 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
- Others have suggested that they would prefer to have MUST and SHOULD
retaining their IETF meanings
- 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 ...
(I can't offhand think of an example of a SHOULD*; perhaps something
like the library-naming business: there may be specific instances
where it has to be done differently, otherwise it's RC. And don't
flame me for this specific example, please; I know I may be wrong
about it.)
Then it's clear that to write a good package all of the above ought
to be satisfied, but only normal-level bugs can be filed against
anything other than the app-defaults stuff.
Does that possibility satisfy everyone:
- MUST and SHOULD change to the universally-recognised IETF meanings
- the distinction between RC and non-RC bugs is retained clearly
- it's clear what one ought to do to create a "good" Debian package
- there's no time component involved
- there's no longer a suggestion of using policy as anything other
than a set of guidelines
And the thought, now an orthogonal one to the above stuff and not
really appropriate on -policy, but this is where it makes sense at
this point:
Did the ftpadmins ever consider the possibility of running lintian on
packages before allowing them into unstable? I vaguely remember that
being discussed in the past.
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: