On Thu, Apr 12, 2001 at 12:05:48AM +0100, Julian Gilbey wrote:
> 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:
*sob*
> 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.
It's quite easy to introduce a new must. If it's a something that's
already causing RC bugs or similar, you:
* work out what you want to have happen
* propose it as a must, describing what breaks and get it accepted
Or if it's just something you think should be standardised (like the FHS
or /usr/doc), you:
* work out what you want to have happen
* propose it as a should, make sure it's accepted
* file bugs, make sure they're all fixed
* propose it to be updated to must, noting that all
packages affected have already changed, and saying
why it's better to throw packages that violate the
guideline out than keep them in
> 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.
Why would this be particularly good? We don't even stop people from
uploading packages that have real RC bugs (even ones detectable by
lintian).
BenC suggested the other day that the testing scripts (which do take RC
bugs into account, although only via the BTS not via lintian) also take
into account dependencies on outdated libraries, so packages depending
on libssl09 or libssl095a wouldn't make it into testing.
You'll also notice, if you do file RC bugs, that testing already
implements this, to some extent: packages already in testing don't get
automatically removed if an RC bug is filed against them, but won't get
updated until any new RC bugs get fixed. (More or less)
> 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.
Every package must comply with the MUST directives of the current policy,
or it doesn't get released. Packages that don't comply with the current
policy's SHOULD directives are buggy.
> - uploads are required to conform to the latest version of policy
> (NMUs excepted?);
So we no longer accept uploads of packages that don't have manpages for
all their binaries?
> - 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.
I have another suggestion. Let's get rid of the "Standards-Version" field
in debian/control and insist all packages must match current policy.
The fact that it's there seems to confuse people into thinking they
don't have to care about current policy. They do.
> 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.
The RFC route is simply not appropriate for Debian. If you're describing
a protocol, you can't ever allow any sort of "bugs" in conformant
implementations. OTOH, we're not really in a position to drop every
package with bugs.
We need some way to decide what the minimum acceptable standard we'll
accept for our stable distribution.
This really should apply to *all* packages, independently of how old they
are or who maintains them: the whole point of standards is to make sure
that when a user installs a package, it behaves in a sensible predictable
way. A user's not going to care whether the package was last uploaded
five days ago or five months ago, nor is a user really likely to accept
that as an excuse for why it's broken or non-conformant.
If you like, we can go back to this being the release manager's
prerogative. It sucks in almost every way, but at least it doesn't have
to get explained on -policy every week.
If you'd rather use different words, or get rid of the footnote
referencing the RFC, fine, sure. Personally, I can't think of any better
words to use, but *shrug*. You could change MUST to WILL, if you wanted,
maybe.
If you want to make policy apply inconsistently to different packages,
well, I think that's just stupid, no matter how many times it's proposed.
It'd help if you'd come up with a clear statement of what you'd like to
achieve, independent of your preferred solution. "Distinguishing between
guidelines that will get a package thrown out of the distribution and
guidelines that won't" is the problem MUST/SHOULD/MAY is designed to
solve, eg.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpThClj2Knwl.pgp
Description: PGP signature