On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek <[EMAIL PROTECTED]> said:
> On Tue, Oct 24, 2006 at 06:48:10PM -0500, Manoj Srivastava wrote:
>> >> If you are aware of issues that are violations of muSt
>> >> directives that are never going to be RC, there should be a bug
>> >> opened on policy with severity important for every one of them.
>> > Why? If these issues are downgraded to "should"s in policy,
>> > doesn't that again introduce ambiguity about whether a violation
>> > of that particular "should" is a bug, unnecessarily weakening the
>> > overall quality of the distro?
>> Why on earth would there be such an ambiguity? Should violations
>> are bugs, or severity normal.
> Non-conformance with guidelines denoted by _should_ (or
> _recommended_) will generally be considered a bug, but will not
> necessarily render a package unsuitable for distribution.
> Is the word "generally" here an error? I read this as implying the
> normal meaning of "should" -- that not everything which violates a
> "should" mandate is a bug.
I am of the opinion that it is. We can replace non-buggy
instances of should by 'ought to be', if needed.
>> And why is the distro quality su=ffering? Aren't the RM's of the
>> opinion that these requirements are not worth following in the
>> first place?
> Hell no. We're of the opinion that these requirements are not
> grounds for *excluding a package from release* -- but I certainly
> don't think that the release team's stick should be the only reason
> for maintainers to comply with the rules set out in policy! And I
Well, maintainers ought to be following the should rules as
well, so there is no reason for the directive to be a must if the bug
is not deemed serious or a reason to keep the package out of the
release until it is fixed.
> don't think maintainers should be left to believe that violations of
> certain directives in policy which are unambiguously the correct
> thing to do should be treated as non-bugs, which is what that
> "generally" implies.
Well, we seem to be in agreement here. However, this change
(removing generally) needs to be ratified by a few more people
before I would be comfortable changing it.
> I also don't think that all "should"s that might not be bugs should
> be automatically shunted to the devref as you suggest, because that
> leaves us with no standardization *process* for policy that we can
> use to get eyeballs on possible bugs in new requirements, AFAICS.
If something is not a requirement, that is, not doing it would
not be considered a bug -- then it does not belong in the normative
part of policy. I think policy should be a minimal document, and
omething which can be unequivocally taken at face value. It is not
supposed to be waffling about, nor a thick tome of best practices. It
is "do this, ot get a bug" book.
It should be easy enough to create a new document that is "it
is kinda nice if you would do this, but, no worries, no bug on your
package if you don't" and submit it to a similar process.
I just don't think that document should be conflated with our
Technical policy.
manoj
--
Some people manage by the book, even though they don't know who wrote
the book or even what book.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
