Re: Must and should again
>>"Julian" == Julian Gilbey <J.D.Gilbey@qmw.ac.uk> writes:
Julian> Must == have to do this, RC bug if don't
Julian> Should == we recommend you do this, normal bug if don't
May == recommended.
Julian> I would much prefer to move to the RFC version with some sort of flag:
Julian> Must == absolute requirement
Julian> Should == requirement except in special circumstances, or:
Julian> highly encouraged
Julian> May == truly optional
Julian> Then there is an indication on each must and should directive whether
Julian> it is yet considered RC.
No. This brings a time factor into the policy; and has been
something we have avoided so far.
Julian> One of the issues is this: it is very hard in the current setup to
Julian> introduce a "must", as it is likely to break a lot of existing
Julian> packages. There are different types of requirements.
Policy should not be used as a stick. If things must be done
this way, they should be done whether or not there is a policy
directive telling us to do the right thing. When packages are
changed over, policy shall be changed to document that.
Julian> Example 1: New X app-defaults location
Julian> This has to be implemented in all affected packages *now*, else
Julian> lots of stuff will break.
Policy is not a catchall for correct methods; we can file bugs
against packages now for not working *right now*. Adding the stick
of policy does not add much -- all you would have is that you could
file policy-violation bugs rather than package breaks bugs.
Julian> Example 2: FHS transition
Julian> Once the tech ctte had decided upon the transition plan, all
Julian> packages should start transitioning. However, there was no need
Julian> for all packages to transition right away. But it would have been
Julian> really good to say: every new upload (NMUs possibly excepted) must
Julian> implement the /usr/doc -> /usr/share/doc transition plan, while
Julian> not filing RC bugs against existing packages.
So there are different rules for different packages? I am not
sure I like the ramifications of this idea.
Julian> - uploads are required to conform to the latest version of policy
Julian> (NMUs excepted?); many aspects of this can be checked using an
Julian> up-to-date version of lintian (but see variant suggestions below)
Julian> - we don't file RC bugs on new requirements until we decide that it
Julian> is necessary and that we are realistically able to fix any packages
Julian> with the issue outstanding in a reasonable length of time
That a) introduces a time component into policy
b) makes it harder to determine whther something is an RC
bug (not all people follow -policy)
Julian> - When introducing a new requirement, there must be sufficient testing
Julian> or code or experience or something to ensure that we're not barking
Julian> up the wrong tree. That would cause a lot of headache. (Consider
Julian> the abortive /var/cache -> /var/state move.) It may thus be wise in
Julian> certain circumstances to introduce these requirements initially as
Julian> recommendations, so that people are not forced to convert their
Julian> packages immediately.
We do that now as a default, so that is no change.
You are trying to shoe horn policy into an enforcement scheme,
and I think this is a bad idea.
manoj
--
"I don't know what their gripe is. A critic is simply someone paid
to render opinions glibly." "Critics are grinks and groinks." Baron
and Badger, from Badger comics
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: