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.
Caveats:
- 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"
anyway.
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
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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/
