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. > 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 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. 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
