[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> On Fri, Apr 13, 2001 at 02:22:54AM +1000, Anthony Towns wrote:
 >> So we no longer accept uploads of packages that don't have manpages for
 >> all their binaries?

 Julian> OK, let's take this example then.  At the moment it's only a "should".

 Julian> Why can't we say that, from now on, we will not accept uploads which
 Julian> fail this?

	If you can get the ftp/katie admin/authors to agree, I can't
 see why not. You all may have some explaining to do, but ...

 Julian> My suggestion is: change "should" to "must" in policy, and give
 Julian> packages some time to migrate (eg., one year) before starting to do
 Julian> NMUs.  Then any packages uploaded within the coming year will have to
 Julian> satisfy this requirement (or have a lintian override if there's a
 Julian> special reason why they don't need to).

	You  are trying to correct a social issue (it is already a
 should directive; people should correct the buggy packages) with a
 technical solution, and it is going to fail. 

	You are going to dilute the meaning of the meaning of must ==
 right now must means ``if not fixed, your package won't go into the
 release/ The new meaning shall be, something that needs to be fixed
 sometime, but ot may ot yet be a RC bug; from your own message that
 is apparently a disincentive for people to act. 

	As to removing the  "undocumented.7" man pages, we can enact a
 policy saying that it needs a normal bug at the creation, in 6 months
 (or whatever) an automated process shall go through and raise the
 severity to RC. No mucking around and fiddling with the strong must
 in policy. 

 >> >  - 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
 >> Indeed. We can do this right now by making them recommendations (should)
 >> instead of requirements (must), and update them later if it's appropriate.

 Julian> So one day you have a minor bug report against your package, the next
 Julian> day it becomes an RC bug report with the threat of your package being
 Julian> pulled.

	No. We just keep the time-line in collective memory, and
 informative footnotes, rather than policy itself; and we follow the
 rule that policy changes never make a significant number of packages

 Julian> Problems:

 Julian>  (1) Many maintainers ignore policy changes and don't apply them to
 Julian>      their packages.  The above statistics give some indication of the
 Julian>      extent of this problem.

	Social problem, needs a social solution.

 Julian>  (2) We don't enforce policy dictates except by filing RC bugs at a
 Julian>      very late stage in the process, once we've decided that the
 Julian>      requirement should be an absolute.

	We can also file non-RC bugs earlier in the process, when
 thery are merely a should directive. Another social problem.

 Julian>  (3) The above two points mean that it is hard to maintain a high
 Julian>      quality of packages in any automated fashion, and that a large
 Julian>      burden is put on a small number of developers who try to fix the
 Julian>      problems thereby caused, for example the /usr/doc ->
 Julian>      /usr/share/doc transition is still not complete.

	And making policy a bigger stick shall not solve the problem

 Julian>  (4) It also means that we are often afraid to "do the right thing"
 Julian>      and demand that packages satisfy certain criteria (all binaries
 Julian>      to have manpages) because too many packages will then receive RC
 Julian>      bugs, even though we should demand this of all packages and it
 Julian>      really isn't an RC issue.

	In some ways, that is a sanity check. Make policy too strict,
 and it shan;t be followed (you guessed it -- a social problem).
 Policy tries to do the right thing, for the most part -- but it also
 tries to stay relevant, by not suddenly making a whole lot of
 packages RC.

	Diluting must does not answer this issue. 

	Even after diluting must, we shall need an external mechanism
 for declaring some ``must'' directive now to be RC, and have this
 external entity enforce the social issues by, I guess, filing RC bugs
 on the diluted must, and facing a barrage of that must is not yet RC

 Julian>  (5) There is only language in policy for "this is an RC requirement"
 Julian>      and "this is a requirement, but not RC".  Both indicate bugs if
 Julian>      there is a failure to comply.  There is no language for: "except
 Julian>      in unusual circumstances, you must do this", which would not
 Julian>      necessarily indicate a bug for lack of compliance.  (For example,
 Julian>      the update-rc.d binary in file-rc need not have a manpage, as it
 Julian>      depends on sysvinit which does.  So maybe the manpage requirement
 Julian>      really ought to be a "should" or needs to explicitly exclude this
 Julian>      type of case.)

	There are always exceptions, and the tech committee is ready to be
 called in to decide when an exception to the policy is

 Julian> Proposal:

 Julian>  (a) Package uploads into unstable must comply with the latest version
 Julian>      of policy (or be no more than, say, one month out of date).
 Julian>      Suggested implementation: lintian could be used to do this, with
 Julian>      a strict check on the Standards-Version.  It would probably be a
 Julian>      slightly rough ride to begin with, but worth it in the long term.
 Julian>      We'd need to figure out what to do with lintian overrides though:
 Julian>      perhaps "must"s could not be overridden but "should"s could be?

	This is an administrative decision, and does not belong in a
 technical policy.

 Julian>  (b) The release manager decides upon a minimum acceptable
 Julian>      Standards-Version for each release once (a) has been implemented.
 Julian>      Most packages will automatically satisfy this requirement due to
 Julian>      the enforcement in (a), especially if the minimum version is no
 Julian>      later that that of the previous released version; I would guess
 Julian>      that >90% of packages are uploaded at least once per year.

	Again, this is the domain of the release manager, and does not
 belong in policy. 

 Julian>  (c) Urgent requirements could be dealt with using the current RC bug
 Julian>      method after being discussed on -policy.

 Julian> Then, as a *corollary* of the above, "must" and "should" would need to
 Julian> change their meanings, as we would have a different way of determining
 Julian> which policy bugs are RC, given in (b).

	GTiven my arguments above, I guess I still need to be
 convinced not to object to diluting the meaning of must.

 "I asked you not to have a spaz attack in tx.general, BUT NOOOOO!!!!"
 Karl, via John Belushi
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: