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
un-releasable.
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
either.
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
arguments.
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
warranted.
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.
manoj
--
"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: