On Sun, Jan 24, 2010 at 11:19:33AM -0800, Russ Allbery wrote: > Ben Finney <ben+deb...@benfinney.id.au> writes: > > Severity-wise, it's the same as "should." Policy is not written in formal > standards language, and certainly here has the normal fuzzy English > meaning. In the first case, for instance, I'd read it as an attempt to > further explain what "brief" means, acknowledging room for disagremeent > short of 80 characters. For the second, the "almost certainly" is an > intensifier on the certainty of the recommendation, but it's still a > recommendation rather than a requirement. > > Anything about the one-line synopsis is, in practice, probably a minor > severity bug even if it's over 80 columns, just because that's the bug > severity used for documentation problems and things that are ugly but > don't break the package.
There are package management programs that depend on the synopsis to be short for proper display. A 90 columns synopsis is probably a minor bug, but a 200 column is probably at least "normal", a 1000 columns synopsis is probably "serious". > > If there's no normative effect, is it reasonable to ask for the sake of > > clarity that these modifiers be struck from the wording? > > If the information they're communicating can be rephrased in some other > way, sure. (In other words, I disagree with simply removing the words.) > > The ideal solution would come as part of a general Policy rewrite to use > more formal and precise language. I am not sure this is desirable. The policy is a technical document and not a legal document and should be easy to read. We should assume that developers will interpret policy in good faith and not try to find loop-hole to justify package brokenness. Making the policy language less natural will negatively affect developpers that read policy to follow it in good faith. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
signature.asc
Description: Digital signature
