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

Re: Must and should again



I've had a thought about my ideas.  I suggest that we all try doing a
'PMI' on them (I will not have a chance now until early next week,
though).  It's a three minute task, and you should be strict about
timing, and works like this:

For one minute, come up with as many Positive thoughts and ideas as
you can about the proposal I've made; note them quickly as you go.

For one minute, come up with as many Negative thoughts and ideas as
you can about the proposal I've made; note them quickly as you go.

For one minute, come up with as many Interesting thought and ideas as
you can about the proposal I've made; note them quickly as you go.
These are things like: here's something it's made me realise; how
about doing it like this; is X really an issue; issue Y has been
ignored.

Then early next week, we can all share what we've come up with.  I'm
sure I've overlooked issues and that this can be improved, but arguing
in the way we have isn't going to do that.  It may even be that
someone will come up with something which will make us think of
a completely different way of handling this, or leaving it as is.

Once again, here was what I wrote:

On Fri, Apr 13, 2001 at 12:49:40AM +0100, Julian Gilbey wrote:
> Problems:
> 
>  (1) Many maintainers ignore policy changes and don't apply them to
>      their packages.  The above statistics give some indication of the
>      extent of this problem.
> 
>  (2) We don't enforce policy dictates except by filing RC bugs at a
>      very late stage in the process, once we've decided that the
>      requirement should be an absolute.
> 
>  (3) The above two points mean that it is hard to maintain a high
>      quality of packages in any automated fashion, and that a large
>      burden is put on a small number of developers who try to fix the
>      problems thereby caused, for example the /usr/doc ->
>      /usr/share/doc transition is still not complete.
> 
>  (4) It also means that we are often afraid to "do the right thing"
>      and demand that packages satisfy certain criteria (all binaries
>      to have manpages) because too many packages will then receive RC
>      bugs, even though we should demand this of all packages and it
>      really isn't an RC issue.
> 
>  (5) There is only language in policy for "this is an RC requirement"
>      and "this is a requirement, but not RC".  Both indicate bugs if
>      there is a failure to comply.  There is no language for: "except
>      in unusual circumstances, you must do this", which would not
>      necessarily indicate a bug for lack of compliance.  (For example,
>      the update-rc.d binary in file-rc need not have a manpage, as it
>      depends on sysvinit which does.  So maybe the manpage requirement
>      really ought to be a "should" or needs to explicitly exclude this
>      type of case.)
> 
> Proposal:
> 
>  (a) Package uploads into unstable must comply with the latest version
>      of policy (or be no more than, say, one month out of date).
>      Suggested implementation: lintian could be used to do this, with
>      a strict check on the Standards-Version.  It would probably be a
>      slightly rough ride to begin with, but worth it in the long term.
>      We'd need to figure out what to do with lintian overrides though:
>      perhaps "must"s could not be overridden but "should"s could be?
> 
>  (b) The release manager decides upon a minimum acceptable
>      Standards-Version for each release once (a) has been implemented.
>      Most packages will automatically satisfy this requirement due to
>      the enforcement in (a), especially if the minimum version is no
>      later that that of the previous released version; I would guess
>      that >90% of packages are uploaded at least once per year.
> 
>  (c) Urgent requirements could be dealt with using the current RC bug
>      method after being discussed on -policy.
> 
> Then, as a *corollary* of the above, "must" and "should" would need to
> change their meanings, as we would have a different way of determining
> which policy bugs are RC, given in (b).

   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: