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

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.

 "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: