Re: Bug mass filling
On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek <email@example.com> 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
Some people manage by the book, even though they don't know who wrote
the book or even what book.
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C