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

Re: Must and should again

On Wed, Apr 11, 2001 at 02:44:26PM -0700, Sean 'Shaleh' Perry wrote:
> On 11-Apr-2001 Julian Gilbey wrote:
> > We don't really have any standard way of saying "you really should do
> > this as it's a really good thing to do, but there's no requirement to
> > do so (and hence not a reason to file bug reports)".
> > 
> I thought we were using RFC definitions of must and should, and thus 'may'
> follows.
> Must == have to do this
> Should == we recommend you do this
> May == we think it is a good idea, but is not always possible/sane/etc

That's not quite what the RFC definitions are (see RFC 2119).

Also, we have a different definition, which I'm not at all happy with
for this reason:

Must == have to do this, RC bug if don't
Should == we recommend you do this, normal bug if don't

I would much prefer to move to the RFC version with some sort of flag:

Must == absolute requirement
Should == requirement except in special circumstances, or:
          highly encouraged
May == truly optional

Then there is an indication on each must and should directive whether
it is yet considered RC.

One of the issues is this: it is very hard in the current setup to
introduce a "must", as it is likely to break a lot of existing
packages.  There are different types of requirements.

Example 1: New X app-defaults location

   This has to be implemented in all affected packages *now*, else
   lots of stuff will break.

Example 2: FHS transition

   Once the tech ctte had decided upon the transition plan, all
   packages should start transitioning.  However, there was no need
   for all packages to transition right away.  But it would have been
   really good to say: every new upload (NMUs possibly excepted) must
   implement the /usr/doc -> /usr/share/doc transition plan, while
   not filing RC bugs against existing packages.

So we have a current version of policy, perhaps with lots of MUST
and SHOULD directives (with the RFC meaning), and then any package
claiming compliance with that version of policy must satisfy them.

Independently, we decide when each requirement becomes considered RC.

So in summary:

 - uploads are required to conform to the latest version of policy
   (NMUs excepted?); many aspects of this can be checked using an
   up-to-date version of lintian (but see variant suggestions below)

 - we don't file RC bugs on new requirements until we decide that it
   is necessary and that we are realistically able to fix any packages
   with the issue outstanding in a reasonable length of time

Then the effects of regular uploads should be adequate to ensure that
all requirements are met within a reasonable space of time, as long as
it is not an urgent need.


- When introducing a new requirement, there must be sufficient testing
  or code or experience or something to ensure that we're not barking
  up the wrong tree.  That would cause a lot of headache.  (Consider
  the abortive /var/cache -> /var/state move.)  It may thus be wise in
  certain circumstances to introduce these requirements initially as
  recommendations, so that people are not forced to convert their
  packages immediately.

- When introducing a requirement/MUST, one must remember that it will
  become an absolute requirement on every package uploaded
  thereafter, and will eventually be required of every existing
  package, as is currently the case.  Thus these should be introduced
  very carefully.

Variant suggestions:

 - uploads could be permitted to be made with a "recent" version of
   policy, where "recent" is, say, < 2 months old

 - in such a case, dinstall/katie could send any lintian errors and
   warnings which are generated from the newest lintian to the
   uploader; this would let them know that there are issues which will
   need to be addressed before the next upload

Lintian would need to be enhanced to know which requirements were
introduced in which version of policy (but only in the future; all of
the existing requirements can be labelled with the current version),
so that the concept of "recently introduced" can be defined; perhaps a
command-line switch to say "how old a policy version we will accept"
would be needed.

I don't think it's worth automating "urgent RC bugs" such as the
example given above: they're relatively rare and can be handled on a
case-by-case basis.  For all other requirements, there would be a
reasonable time-lag between it becoming policy and it becoming RC, in
which time the policy version without it would be considered "too old"

Does any of this sound reasonable?  Anthony, what do you think of it?
I know you've always gone by the "must = RC" route, but there are lots
of people getting really confused by this whole thing, and I think
that the RFC route is the far better known.



         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: