Re: Bug mass filling
Manoj Srivastava writes (Re: Bug mass filling): On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson [EMAIL PROTECTED] said: There are two different and orthogonal properties of a policy requirement: 1. [...] [and] 2. Is a violation of the requirement release-critical ? That is, would it be better to remove the package (or to stick with the old version of the package) than to live with this bug ? I posit the second one is not a characteristic of the policy requirement; it is a characteristic of the bug. Well, yes. My stance is that bug severity tags are tied to policy violations, since that can be determined mechanically; violate a must directive, bug is serious. Whether or not all serious bugs are RC is anothermatter that the release team determines; hence the *-ignore tags. Why on earth is it useful to encode some scripturally-determined property of a bug in the severity ? The use for the severity is to 1. allow us to record whether the bug is release critical (which is definitely something we need to track) and 2. allow the project to prioritise its work (which is also something we need to track). Helpfully we can use the same linear scale for both because all release-critical bugs should always have a higher priority than all non-release-critical bugs. The problem is, since this involves human judgement, one can no longer state in policy what category a must violation of policy falls into; policy must waffle with well, if you find a policy violation, fgiure out what severity the ciolation would be, consult your feelings, other peoples feelings, release managers, and perhaps the phase of the moon. This is a completely bizarre assertion. If you're submitting a bug you can look at the BTS web page which gives clear definitions of all of the bug severities. There is only one significant problem with the list at http://www.debian.org/Bugs/Developer#severities which is the definition of `serious'. It should be replaced with: serious Release critical bugs (other than `grave' and `critical' bugs); see also the Release Managers' policy at URL. Do not set this severity unless it would be better to remove the package from the distribution than to ship it with this bug. The final decision about whether a bug is release critical rests with the Release Managers. Obviously there is room for judgement here by the submitter and the maintainer - but we rely on our colleagues to make the right decisions in all sorts of areas. Since we already feel that our RM's are overworked (hence dunc-tank and payment schemes), I strongly suggest we not add to the RM's burdens any more than we have to. If the RMs want to write a document saying what counts as a release critical bug, can do so. And lo, look, they have. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, 26 Oct 2006 12:02:31 +0100, Ian Jackson [EMAIL PROTECTED] said: Manoj Srivastava writes (Re: Bug mass filling): On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson [EMAIL PROTECTED] said: There are two different and orthogonal properties of a policy requirement: 1. [...] [and] 2. Is a violation of the requirement release-critical ? That is, would it be better to remove the package (or to stick with the old version of the package) than to live with this bug ? I posit the second one is not a characteristic of the policy requirement; it is a characteristic of the bug. Well, yes. My stance is that bug severity tags are tied to policy violations, since that can be determined mechanically; violate a must directive, bug is serious. Whether or not all serious bugs are RC is anothermatter that the release team determines; hence the *-ignore tags. Why on earth is it useful to encode some scripturally-determined property of a bug in the severity ? Because developers and bug reporters are human, and may need some guidance about bug severities, and The use for the severity is to 1. allow us to record whether the bug is release critical (which is definitely something we need to track) and 2. allow the project to prioritise its work (which is also something we need to track). Helpfully we can use the same linear scale for both because all release-critical bugs should always have a higher priority than all non-release-critical bugs. A very developer centric view. But there are other pepople in the community; and as a general statement this falls far short of the mark for which bug severities are actually useful for. Bug severities have one other purpose, and perhaps the most importan of all: It lets people know whether or not it is OK to upgrade or install a package, and but severities are one way of gauging a release' quality. While only partially relevant to this case, you are making what seems like a general statement, and missing important bits. The problem is, since this involves human judgement, one can no longer state in policy what category a must violation of policy falls into; policy must waffle with well, if you find a policy violation, fgiure out what severity the ciolation would be, consult your feelings, other peoples feelings, release managers, and perhaps the phase of the moon. This is a completely bizarre assertion. If you're submitting a bug you can look at the BTS web page which gives clear definitions of all of the bug severities. I see you are trolling. However, I suppose I can say I have been trolled, since I am going to reply anyway. People do not work like that. Simply ignoring the way people report bugs, and pretending that every one looks at all kinds of unrelated bug reports and cogently arrives at a working, consistent, and borderline correct severity may work in an, ahem, bizarre world you live in, but does not work on planet earth. So, policy guidelines as to bug severities are a cheap way to arrive at a consistent default for bug severities, and there is no reason not to add such guidance, as long as the guidelines are flexible, and, more importantly, correct. There is only one significant problem with the list at http://www.debian.org/Bugs/Developer#severitieswhich is the definition of `serious'. It should be replaced with: May I suggest that his opinion is perhaps as, umm, ridiculous, as the rest of your rant? Obviously there is room for judgement here by the submitter and the maintainer - but we rely on our colleagues to make the right decisions in all sorts of areas. Jindani. manoj -- All things that are, are with more spirit chased than enjoyed. Shakespeare, Merchant of Venice 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]
Re: Bug mass filling
On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote: So certain bugs can be marked $STABLE-ignore to allow transient rc issues to be ignored for a release and will become no-ops after release. Are you suggesting that each package can have a related list of non-transient bugs that should be marked (with a new tags called ) ignore-this-policy-violation where this can be attached to any package related bug for any length of time until the issues is deemed worthy/necessary to be addressed? If a rule defining a bug ended in the policy document, it certainly is worthy of being addressed. As Manoj expressed several times, if a bug can be ignored for an arbitrary length of time, it certainly should be a note in the developer reference and not a sentence in the policy document. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]: 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. I hope to have time post-etch-release to do that (that is what I meant with syncing between policy and release-policy). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
should, ought, must (was: Bug mass filling)
Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek [EMAIL PROTECTED] said: 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. But please don't forget a legal definition of those terms. For me, as a non-native speaker, I have no idea whether ought to is weaker or stronger than should, or just something different (and what). Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug mass filling
Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek [EMAIL PROTECTED] said: Because your choice of mapping blurs the distinction between one-time exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy violations that the release team does not believe should be promoted to RC status at any time in the foreseeable future. etch-ignore is most useful as a tag if its use is restricted to those bugs whose *non*-release-criticality is transient in nature -- the alternative is that the release team is stuck going through the BTS after each release and re-adding new tags to those bugs about policy violations whose severity does not justify exclusion from the release. That does not make sense. After etch is released, etch-ignore tags are no-ops -- so there is no need to go back and untag anything. The work would be to change the tag to whatever-ignore. And if there are anyissues that are policy must directives that the release team has take upon itself to say are policy directives it is not worth following, then they should file important bugs against polocuy to either have the requirements removed, or the issue resovled by the tech ctte. I don't like your wording of not worth following. A policy dictum might well be important to follow, but non-conformance may still (always or in particular cases) not be a reason to exclude it from the release. But you're of course right that Policy and the release-policy should be synchronized... Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: should, ought, must (was: Bug mass filling)
* Frank Küster ([EMAIL PROTECTED]) [061025 09:49]: Manoj Srivastava [EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek [EMAIL PROTECTED] said: 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. But please don't forget a legal definition of those terms. For me, as a non-native speaker, I have no idea whether ought to is weaker or stronger than should, or just something different (and what). I think we should (hehe) use the same definitions as the RFCs - or is this text non-DFSG-free? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote: Are you suggesting that each package can have a related list of non-transient bugs that should be marked (with a new tags called ) ignore-this-policy-violation where this can be attached to any package related bug for any length of time until the issues is deemed worthy/necessary to be addressed? No. Why would anyone want this when downgrading these bugs to important has the same effect in all respects and doesn't require changing code in 20 different places to account for a change in semantics? -- 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]
Re: Bug mass filling
On Wed, 25 Oct 2006 09:31:42 +0200, Andreas Barth [EMAIL PROTECTED] said: * Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]: 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. I hope to have time post-etch-release to do that (that is what I meant with syncing between policy and release-policy). Thanks. Your input shall be appreciated -- in the mean while, those of us with time and the inclination can work on fixing the low hanging errors, so you may find your work later reduced a bit. manoj -- The more complex the mind, the greater the need for the simplicity of play. Kirk, Shore Leave, stardate 3025.8 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]
Re: Bug mass filling
On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava [EMAIL PROTECTED] said: [...] and for policy: These classifications are roughly equivalent to the bug severities serious (for must or required directive violations), minor, normal or important (for should or recommended directive violations) and wishlist (for optional items). [2] However, this is not a direct mapping, and the release managers determine which violations are considered release-critical. where does release criticality jump in here from? Policy has no mention of RC in this context, I see no reason to suddenly inject one. Well, I did say that it was a very rough draft. ;) Second try: ... However, this is not a direct mapping, and the release managers determine the severity of each violation. The problem is there are two mappings, one from policy violations over to bug severities, and another from severities to RC. The former is , according to policy, pretty static; the latter is, by the release team directive, a fluid mapping based on the contents of a web page, which is updated by the RM's as needed. I don't see any reason to fuzzy up the first mapping; and I see the etch-ignore tag as a perfectly legitimate and adequate representation of the fluidity of the second mapping. From my reading, the language for the first mapping is already a bit fuzzy, since both places that define the mapping use the word roughly. So I think that we should either make it explicitly fuzzy by changing the wording, or make it explicitly not fuzzy by removing the word roughly (and possibly changing policy to reflect reality). I also would prefer if the first mapping wasn't fuzzy. But it sounds to me like the release team is reading it as being a fuzzy mapping (AFAICT), in which case I would suggest making it more clear that the mapping is fuzzy. -- Hubert Chan [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Manoj Srivastava writes (Re: Bug mass filling): On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek [EMAIL PROTECTED] said: When there are issues addressed in policy that are black-and-white where all violations of the policy requirement are definitely bugs, but not all such violations should be grounds for keeping a package out of a release, how do you suggest such rules should be handled in the normative language of policy, and how do you suggest that the related bugs be handled in the BTS? Gee. Don't we already have something very like this? These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] There are two different and orthogonal properties of a policy requirement: 1. Is the requirement applicable in all cases, or are there sometimes overriding reasons to it another way, or exceptional cases where the requirement ought not to apply ? 2. Is a violation of the requirement release-critical ? That is, would it be better to remove the package (or to stick with the old version of the package) than to live with this bug ? I'm happy that the policy manual should itself determine the answer to the first question; and this is the conventional distinction between `must' vs `should'. But the second question is much more subtle, and also isn't properly decided by the process that maintains the policy manual. It should be probably be decided by the package maintainer in the first instance; with the release managers giving both general guidance and specific advice, and having the final decision. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson [EMAIL PROTECTED] said: Manoj Srivastava writes (Re: Bug mass filling): On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek [EMAIL PROTECTED] said: When there are issues addressed in policy that are black-and-white where all violations of the policy requirement are definitely bugs, but not all such violations should be grounds for keeping a package out of a release, how do you suggest such rules should be handled in the normative language of policy, and how do you suggest that the related bugs be handled in the BTS? Gee. Don't we already have something very like this? These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] There are two different and orthogonal properties of a policy requirement: I posit the second one is not a characteristic of the policy requirement; it is a characteristic of the bug. 1. Is the requirement applicable in all cases, or are there sometimes overriding reasons to it another way, or exceptional cases where the requirement ought not to apply ? 2. Is a violation of the requirement release-critical ? That is, would it be better to remove the package (or to stick with the old version of the package) than to live with this bug ? I'm happy that the policy manual should itself determine the answer to the first question; and this is the conventional distinction between `must' vs `should'. But the second question is much more subtle, and also isn't properly decided by the process that maintains the policy manual. It should be probably be decided by the package maintainer in the first instance; with the release managers giving both general guidance and specific advice, and having the final decision. Nothing you have said contradicts either what I or aba have said; the devil lies in the details you have elided. My stance is that bug severity tags are tied to policy violations, since that can be determined mechanically; violate a must directive, bug is serious. Whether or not all serious bugs are RC is anothermatter that the release team determines; hence the *-ignore tags. Andreas is of the opinion we should instead have all serious bugs be RC, violations of policy must directives that are not RC should be downgraded. The problem is, since this involves human judgement, one can no longer state in policy what category a must violation of policy falls into; policy must waffle with well, if you find a policy violation, fgiure out what severity the ciolation would be, consult your feelings, other peoples feelings, release managers, and perhaps the phase of the moon. Unlike the decision of whether a seirous bug is RC under my proposal, where the word of the RM is law; there is no final authority about the severity of a policy violation bug under the alternate proposal. Any maintainer is then free to insist that his violation of a bug would not be RC, anyway, and downgrade the bug; it would mean that the RM's would have to be brought in every time there is a violation of policy. Since we already feel that our RM's are overworked (hence dunc-tank and payment schemes), I strongly suggest we not add to the RM's burdens any more than we have to. manoj -- He gave her a look that you could have poured on a waffle. 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]
Re: Bug mass filling
On Tue, 24 Oct 2006 07:21:35 +0200, Andreas Barth [EMAIL PROTECTED] said: * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]: Strawman. No one is proosing that; we already have a mechanism for making serious bugs non-RC (etch-ignore tags). Etch-ignore tags are usually used for issues where we expect them to be RC after etch releases. If we think an issue won't be RC for etch+1 etc, then adjusting the severity is correct. I would assume violations of policy MUST directives are either bugs in policy, which should be fixed, or an issue in the package that needs to be fixed after etch releases. 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. manoj -- Any discovery is more likely to be exploited by the wicked than applied by the virtuous. -- Marion J. Levy, Jr. 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]
Re: Bug mass filling
On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan [EMAIL PROTECTED] said: On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava [EMAIL PROTECTED] said: [...] and for policy: These classifications are roughly equivalent to the bug severities serious (for must or required directive violations), minor, normal or important (for should or recommended directive violations) and wishlist (for optional items). [2] However, this is not a direct mapping, and the release managers determine which violations are considered release-critical. where does release criticality jump in here from? Policy has no mention of RC in this context, I see no reason to suddenly inject one. Well, I did say that it was a very rough draft. ;) Second try: ... However, this is not a direct mapping, and the release managers determine the severity of each violation. Direct mapping of *WHAT*? are you falling into the assumption that serious == RC? Why? manoj -- Hard work never killed anybody, but why take a chance? Charlie McCarthy 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]
Re: Bug mass filling
On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote: Well, I did say that it was a very rough draft. ;) Second try: ... However, this is not a direct mapping, and the release managers determine the severity of each violation. Direct mapping of *WHAT*? are you falling into the assumption that serious == RC? Why? Because your choice of mapping blurs the distinction between one-time exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy violations that the release team does not believe should be promoted to RC status at any time in the foreseeable future. etch-ignore is most useful as a tag if its use is restricted to those bugs whose *non*-release-criticality is transient in nature -- the alternative is that the release team is stuck going through the BTS after each release and re-adding new tags to those bugs about policy violations whose severity does not justify exclusion from the release. -- 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]
Re: Bug mass filling
On Tue, Oct 24, 2006 at 04:51:08PM -0500, Manoj Srivastava wrote: * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]: Strawman. No one is proosing that; we already have a mechanism for making serious bugs non-RC (etch-ignore tags). Etch-ignore tags are usually used for issues where we expect them to be RC after etch releases. If we think an issue won't be RC for etch+1 etc, then adjusting the severity is correct. I would assume violations of policy MUST directives are either bugs in policy, which should be fixed, or an issue in the package that needs to be fixed after etch releases. 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 shoulds 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? Cheers, -- 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]
Re: Bug mass filling
On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek [EMAIL PROTECTED] said: On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote: Well, I did say that it was a very rough draft. ;) Second try: ... However, this is not a direct mapping, and the release managers determine the severity of each violation. Direct mapping of *WHAT*? are you falling into the assumption that serious == RC? Why? Because your choice of mapping blurs the distinction between one-time exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy violations that the release team does not believe should be promoted to RC status at any time in the foreseeable future. etch-ignore is most useful as a tag if its use is restricted to those bugs whose *non*-release-criticality is transient in nature -- the alternative is that the release team is stuck going through the BTS after each release and re-adding new tags to those bugs about policy violations whose severity does not justify exclusion from the release. That does not make sense. After etch is released, etch-ignore tags are no-ops -- so there is no need to go back and untag anything. And if there are anyissues that are policy must directives that the release team has take upon itself to say are policy directives it is not worth following, then they should file important bugs against polocuy to either have the requirements removed, or the issue resovled by the tech ctte. This bit about Oh, lets just ignore policy, for we know better is absolutely the wrong way to go about this. Fixing policy is the right way. manoj -- Concept, n.: Any idea for which an outside consultant billed you more than $25,000. 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]
Re: Bug mass filling
On Tue, 24 Oct 2006 16:18:11 -0700, Steve Langasek [EMAIL PROTECTED] said: On Tue, Oct 24, 2006 at 04:51:08PM -0500, Manoj Srivastava wrote: * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]: Strawman. No one is proosing that; we already have a mechanism for making serious bugs non-RC (etch-ignore tags). Etch-ignore tags are usually used for issues where we expect them to be RC after etch releases. If we think an issue won't be RC for etch+1 etc, then adjusting the severity is correct. I would assume violations of policy MUST directives are either bugs in policy, which should be fixed, or an issue in the package that needs to be fixed after etch releases. 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 shoulds 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. 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? Either the policy dictum has to be followed, and a bug results (must - serious; should - normal), or the dictum should be removed from policy and moved to, say, dev ref. manoj -- I can give you my word, but I know what it's worth and you don't. Nero Wolfe, Over My Dead Body 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]
Re: Bug mass filling
On Tue, 24 Oct 2006 17:00:45 -0500, Manoj Srivastava [EMAIL PROTECTED] said: On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan [EMAIL PROTECTED] said: On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava [EMAIL PROTECTED] said: [...] and for policy: These classifications are roughly equivalent to the bug severities serious (for must or required directive violations), minor, normal or important (for should or recommended directive violations) and wishlist (for optional items). [2] However, this is not a direct mapping, and the release managers determine which violations are considered release-critical. where does release criticality jump in here from? Policy has no mention of RC in this context, I see no reason to suddenly inject one. Well, I did say that it was a very rough draft. ;) Second try: ... However, this is not a direct mapping, and the release managers determine the severity of each violation. Direct mapping of *WHAT*? are you falling into the assumption that serious == RC? Why? No, the previous sentence (which is what we currently have in policy) defines a mapping of serious bug = must/required directive violation, and minor/normal/important bug = should/recommended directive violation, and wishlist bug = optional. That's the mapping that it is referring to. My understanding is that the release team treats that as an approximate mapping, and the current wording of policy allows this due to the use of the word roughly. (Mapping may not be the best word to use in policy. But like I said, it's a rough draft.) -- Hubert Chan [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
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 shoulds 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 shoulds 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]
Re: Bug mass filling
On Tue, Oct 24, 2006 at 04:36:52PM -0500, Manoj Srivastava wrote: Since we already feel that our RM's are overworked (hence dunc-tank and payment schemes), I strongly suggest we not add to the RM's burdens any more than we have to. This is a laughable suggestion, given that the RMs' time is now being taken up defending the longstanding handling of BTS severities in this thread, when that is handling is precisely the one that, IME, minimizes the amount of work the release team should have to do to manually review bug states. -- 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]
Re: Bug mass filling
On Tue, 24 Oct 2006 18:36:43 -0700, Steve Langasek [EMAIL PROTECTED] said: On Tue, Oct 24, 2006 at 04:36:52PM -0500, Manoj Srivastava wrote: Since we already feel that our RM's are overworked (hence dunc-tank and payment schemes), I strongly suggest we not add to the RM's burdens any more than we have to. This is a laughable suggestion, given that the RMs' time is now being taken up defending the longstanding handling of BTS severities in this thread, when that is handling is precisely the one that, IME, minimizes the amount of work the release team should have to do to manually review bug states. So, you want to be called in for every policy violation bug to weigh in on the severity? Sounds like that would increase the load. Just answering this question in the affiirmative would stop this thread of discussion dead in its tracks. manoj -- Honi soit la vache qui rit. 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]
Re: Bug mass filling
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 shoulds 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 shoulds 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]
Re: Bug mass filling
On Tue, Oct 24, 2006 at 04:04:54PM -0700, Steve Langasek wrote: On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote: Well, I did say that it was a very rough draft. ;) Second try: ... However, this is not a direct mapping, and the release managers determine the severity of each violation. Direct mapping of *WHAT*? are you falling into the assumption that serious == RC? Why? Because your choice of mapping blurs the distinction between one-time exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy violations that the release team does not believe should be promoted to RC status at any time in the foreseeable future. etch-ignore is most useful as a tag if its use is restricted to those bugs whose *non*-release-criticality is transient in nature -- the alternative is that the release team is stuck going through the BTS after each release and re-adding new tags to those bugs about policy violations whose severity does not justify exclusion from the release. Hi, So certain bugs can be marked $STABLE-ignore to allow transient rc issues to be ignored for a release and will become no-ops after release. Are you suggesting that each package can have a related list of non-transient bugs that should be marked (with a new tags called ) ignore-this-policy-violation where this can be attached to any package related bug for any length of time until the issues is deemed worthy/necessary to be addressed? pandora-inspired, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Bug mass filling
On Sun, Oct 22, 2006 at 10:48:26PM -0700, Russ Allbery wrote: I don't think using any non-POSIX feature should be a policy violation, probably. There are some that are in such widespread use and are supported by all shells that weren't written specifically as test suites that I think it's worthwhile making an exception for them. But using general bash features in /bin/sh scripts really do break real systems. How about instead of speaking about POSIX, policy should just list the shells that are officially supported as /bin/sh? There is no need listing every shell, just a representative subset: bash (obviously), dash (it's popular) and an other minimalistic shell (posh?) to prevent allowing everything the kitchen sink if dash starts to rapidly acquire new features. If a maintainer script does not work with a shell on the list - serious bug, if it does not work with some other shell - wishlist bug. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sun October 22 2006 23:22, Manoj Srivastava wrote: I still think we should go for quality of implementation. I also seem to be a minority in this regard. I sincerely hope not. If the project feels that we should downgrade policy not to set our maintainer scripts to allow for the admin to set /bin/sh to be not bash, they can file a bug on policy, and so indicate their belief on the bug reprot; I'll reluctantly degrade policy. As long as Debian allows alternatives to /bin/sh - /bin/bash, the only bugs which should be filed, afaict, are those against packages whose scripts specify /bin/sh and fail to work with any sh but bash... clearly they are buggy and should be specifying /bin/bash as their command interpreter. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Gabor Gombas [EMAIL PROTECTED] writes: How about instead of speaking about POSIX, policy should just list the shells that are officially supported as /bin/sh? There is no need listing every shell, just a representative subset: bash (obviously), dash (it's popular) and an other minimalistic shell (posh?) to prevent allowing everything the kitchen sink if dash starts to rapidly acquire new features. You could say the script _should_ be POSIX compliant and _must_ work with bash, dash, ash... Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sat, 21 Oct 2006 15:40:28 -0500, Manoj Srivastava [EMAIL PROTECTED] said: Gee. Don't we already have something very like this? These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] Well, it says ... _roughly_ equivalent. So it seems to me that both places (http://www.debian.org/Bugs/Developer and policy section 1.1) that attempt to correlate policy violations and bug severity do so with some hedging, and do not try to define a direct mapping. Given the amount of confusion on the issue (the single word roughly is easily missed), I think that it would be a good idea to either update policy so that must/required violations correspond exactly to the release team's definition of release-critical, or to change the wording to make it more explicit that a must/required violation is not necessarily release-critical. For the second option, (a very rough draft of) possible changed wording for www.debian.org/Bugs/Developer is: serious is a severe violation of Debian policy (roughly, it violates a must or required directive, although the severity of a policy violation is determined by the release managers), or, in the ... and for policy: These classifications are roughly equivalent to the bug severities serious (for must or required directive violations), minor, normal or important (for should or recommended directive violations) and wishlist (for optional items). [2] However, this is not a direct mapping, and the release managers determine which violations are considered release-critical. -- Hubert Chan [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sun, 22 Oct 2006 22:48:26 -0700, Russ Allbery [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: I personally think that maintainer scripts should allow for /bin/sh to be not bash; or there should be documentation to the effect that non bash /bin/sh is not supported. People actually use non-bash shells as /bin/sh and I get real bugs filed against my packages when this doesn't work. (Usually they're using ash instead.) The recent effort to speed up the boot process also achieved noticable gains by switching from bash to ash, so I expect that will prompt more people to try this. I don't think using any non-POSIX feature should be a policy violation, probably. There are some that are in such widespread use and are supported by all shells that weren't written specifically as test suites that I think it's worthwhile making an exception for them. But using general bash features in /bin/sh scripts really do break real systems. refinement of the policy language is always welcome. This is tension between quality of implementation (making sure that maintianer scripts do not fall on their faces wehen the user takes the supported action of chaning /bin/sh, and the new fangled rush to push things out on time, ready or not, that makes such bugs non RC. I still think we should go for quality of implementation. I also seem to be a minority in this regard. I think it's reasonable to make some tradeoffs between release quality and making a formal release that is a substantial improvement over stable. If we try to get *everything*, we're basically leaving people with stable and all of the RC bugs that were already in stable and have since been discovered. Strawman. No one is proosing that; we already have a mechanism for making serious bugs non-RC (etch-ignore tags). manoj -- We have phasers, I vote we blast 'em! Bailey, The Corbomite Maneuver, stardate 1514.2 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]
Re: Bug mass filling
On Mon, 23 Oct 2006 12:05:09 +0200, Gabor Gombas [EMAIL PROTECTED] said: On Sun, Oct 22, 2006 at 10:48:26PM -0700, Russ Allbery wrote: I don't think using any non-POSIX feature should be a policy violation, probably. There are some that are in such widespread use and are supported by all shells that weren't written specifically as test suites that I think it's worthwhile making an exception for them. But using general bash features in /bin/sh scripts really do break real systems. How about instead of speaking about POSIX, policy should just list the shells that are officially supported as /bin/sh? There is no need listing every shell, just a representative subset: bash (obviously), dash (it's popular) and an other minimalistic shell (posh?) to prevent allowing everything the kitchen sink if dash starts to rapidly acquire new features. If a maintainer script does not work with a shell on the list - serious bug, if it does not work with some other shell - wishlist bug. Policy is a slowly changing document, so it was deemed too much of a burden for the list of shells to be maintained in policy; but I have no fundamental objections to this approach. manoj -- Refreshed by a brief blackout, I got to my feet and went next door. Martin Amis, _Money_ 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]
Re: Bug mass filling
On Mon, 23 Oct 2006 12:30:20 -0400, Hubert Chan [EMAIL PROTECTED] said: On Sat, 21 Oct 2006 15:40:28 -0500, Manoj Srivastava [EMAIL PROTECTED] said: Gee. Don't we already have something very like this? These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] Well, it says ... _roughly_ equivalent. So it seems to me that both places (http://www.debian.org/Bugs/Developer and policy section 1.1) that attempt to correlate policy violations and bug severity do so with some hedging, and do not try to define a direct mapping. Err, you seem to be assuming that there is a direct mapping between bug severity and RC-ness, which is not the case. and for policy: These classifications are roughly equivalent to the bug severities serious (for must or required directive violations), minor, normal or important (for should or recommended directive violations) and wishlist (for optional items). [2] However, this is not a direct mapping, and the release managers determine which violations are considered release-critical. where does release criticality jump in here from? Policy has no mention of RC in this context, I see no reason to suddenly inject one. The problem is there are two mappings, one from policy violations over to bug severities, and another from severities to RC. The former is , according to policy, pretty static; the latter is, by the release team directive, a fluid mapping based on the contents of a web page, which is updated by the RM's as needed. I don't see any reason to fuzzy up the first mapping; and I see the etch-ignore tag as a perfectly legitimate and adequate representation of the fluidity of the second mapping. manoj -- I only touch base with reality on an as-needed basis! Royal Floyd Mengot (Klaus) 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]
Re: Bug mass filling
* Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]: Strawman. No one is proosing that; we already have a mechanism for making serious bugs non-RC (etch-ignore tags). Etch-ignore tags are usually used for issues where we expect them to be RC after etch releases. If we think an issue won't be RC for etch+1 etc, then adjusting the severity is correct. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
(Yes, I'm on vacation, and really am still on vacation, but I had a brief check-in moment and happened to see this thread. Note that I probably won't see responses, unless I get to them tomorrow night, until the beginning of November.) Aurelien Jarno [EMAIL PROTECTED] writes: I have just run lintian on all the archive (amd64) for both binaries and sources, and the results are a bit scary. It looks like a lot of maintainers are uploading their packages, and don't really care with the policy. Maybe some errors (E:) of lintian could be changed to critical (C:) and uploads containing such critical errors be refused by dak? What do you think? Please note that lintian considers *any* violation of policy, even things that in practice won't cause problems, to be worthy of E:. In this particular case: Among all of the bugs reported by lintian, one concerns a lot of packages, the presence of the clean, binary, binary-arch, binary-indep and build targets. This is required by both the section 4.9 of the policy and the Etch release standards [1]. Here is the list of affected packages. What to do with them? what's generally going on is that the package builds only arch-dependent or arch-independent packages and therefore the missing target is a no-op. Due to the way that the autobuilders work and the normal package building tools work, in practice this will almost never be noticed. However, policy *does* require that the targets exist, so lintian dutifully diagnoses the problem. Another common lintian error that doesn't cause problems in practice (now) is that lintian intentionally does not take transitive dependencies into account when checking package dependencies and build dependencies. This means that if, for instance, your debian/rules calls a program from po-debconf, lintian will complain if you don't build-depend on po-debconf, even if you're already build-depending on debhelper which in turn build-depends on po-debconf. This is because reliance on transitive dependencies in general creates dormant RC bugs. If for some reason (and I realize that this is unlikely, but one can construct reasons why it might happen) debhelper drops or downgrades its dependency on po-debconf, all those packages that just relied on debhelper to pull in po-debconf immediately are RC-buggy. Adding an explicit dependency is easy and avoids this problem. (If, however, a package is *defined* as being equivalent to depending on another package, I'm willing to teach lintian about those special cases, the same as how it handles virtual packages like c-shell now.) I've put a lot of work into lintian over the past six months focused specifically on eliminating false positives, so I'd love it if people would run the unstable lintian regularly on packages and report as bugs any false positives that don't look unavoidable. (lintian -i will often give you clues as to whether the false positive is unavoidable; if lintian -i specifically recommends an override, that generally means that the lintian maintainers believe it infeasible to entirely avoid false positives there.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sat, Oct 21, 2006 at 07:39:47PM -0500, Manoj Srivastava wrote: Is a bashism in a /bin/sh script a normal bug (should only use POSIX features), or a RC bug (the appropriate shell bust be specified)? It's much easier to work out by just looking at the rc_policy text file maintained by the RM team [1]. Neither. It is a non RC serious bug. No, it's not. It's a minor/normal bug in the package, and a bug in policy that it's implied to be a serious bug. Cheers, aj signature.asc Description: Digital signature
Re: Bug mass filling
On Mon, 23 Oct 2006 12:24:29 +1000, Anthony Towns aj@azure.humbug.org.au said: On Sat, Oct 21, 2006 at 07:39:47PM -0500, Manoj Srivastava wrote: Is a bashism in a /bin/sh script a normal bug (should only use POSIX features), or a RC bug (the appropriate shell bust be specified)? It's much easier to work out by just looking at the rc_policy text file maintained by the RM team [1]. Neither. It is a non RC serious bug. No, it's not. It's a minor/normal bug in the package, and a bug in policy that it's implied to be a serious bug. Can you point me to the bug number of the policy bug? I personally think that maintainer scripts should allow for /bin/sh to be not bash; or there should be documentation to the effect that non bash /bin/sh is not supported. This is tension between quality of implementation (making sure that maintianer scripts do not fall on their faces wehen the user takes the supported action of chaning /bin/sh, and the new fangled rush to push things out on time, ready or not, that makes such bugs non RC. I still think we should go for quality of implementation. I also seem to be a minority in this regard. If the project feels that we should downgrade policy not to set our maintainer scripts to allow for the admin to set /bin/sh to be not bash, they can file a bug on policy, and so indicate their belief on the bug reprot; I'll reluctantly degrade policy. manoj -- How many teamsters does it take to screw in a light bulb? FIFTEEN!! YOU GOT A PROBLEM WITH THAT? 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]
Re: Bug mass filling
Manoj Srivastava [EMAIL PROTECTED] writes: I personally think that maintainer scripts should allow for /bin/sh to be not bash; or there should be documentation to the effect that non bash /bin/sh is not supported. People actually use non-bash shells as /bin/sh and I get real bugs filed against my packages when this doesn't work. (Usually they're using ash instead.) The recent effort to speed up the boot process also achieved noticable gains by switching from bash to ash, so I expect that will prompt more people to try this. I don't think using any non-POSIX feature should be a policy violation, probably. There are some that are in such widespread use and are supported by all shells that weren't written specifically as test suites that I think it's worthwhile making an exception for them. But using general bash features in /bin/sh scripts really do break real systems. This is tension between quality of implementation (making sure that maintianer scripts do not fall on their faces wehen the user takes the supported action of chaning /bin/sh, and the new fangled rush to push things out on time, ready or not, that makes such bugs non RC. I still think we should go for quality of implementation. I also seem to be a minority in this regard. I think it's reasonable to make some tradeoffs between release quality and making a formal release that is a substantial improvement over stable. If we try to get *everything*, we're basically leaving people with stable and all of the RC bugs that were already in stable and have since been discovered. There are some policy violations (such as ensuring every package has binary-arch and binary-indep targets) that require a *lot* of package maintainer bugging and NMUs. I think it's reasonable to tackle a few of those for each release, and probably biting off more than we can chew to try to tackle every one of them for a given release. But, this does require that we try to prevent backsliding, and if we've done a big push to get rid of a policy violation, we should keep that violation RC for subsequent releases. If it's not important enough to go fix every package that has the problem, I think we should question whether it's correct to have it be a requirement in policy. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Please hold off on filing them for a few days, so I can add usertag-on-submit support to debbugs, so that it should be possible to ^^ *that* will be a great feature..:) signature.asc Description: Digital signature
Re: Bug mass filling
On Sat, 21 Oct 2006, Christian Perrier wrote: Please hold off on filing them for a few days, so I can add usertag-on-submit support to debbugs, so that it should be possible to ^^ *that* will be a great feature..:) This should in theory be working now. Usertag: fooblehtag should set the fooblehtag of the user sending the mail. Don Armstrong -- If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money it values more, it will lose that, too. -- W. Somerset Maugham http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Don Armstrong ([EMAIL PROTECTED]) [061021 09:54]: On Sat, 21 Oct 2006, Christian Perrier wrote: Please hold off on filing them for a few days, so I can add usertag-on-submit support to debbugs, so that it should be possible to ^^ *that* will be a great feature..:) This should in theory be working now. Usertag: fooblehtag should set the fooblehtag of the user sending the mail. How can I set usertags of another user (or rather roleaccount) during submission? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sat, 21 Oct 2006, Andreas Barth wrote: * Don Armstrong ([EMAIL PROTECTED]) [061021 09:54]: On Sat, 21 Oct 2006, Christian Perrier wrote: Please hold off on filing them for a few days, so I can add usertag-on-submit support to debbugs, so that it should be possible to ^^ *that* will be a great feature..:) This should in theory be working now. Usertag: fooblehtag should set the fooblehtag of the user sending the mail. How can I set usertags of another user (or rather roleaccount) during submission? Well, once I wake up a bit, you'll be able to go: Package: foopkg User: username Usertags: fooblehtag,bartag [But it won't work for setting multiple users... to do that, you'll have to use control.] Don Armstrong -- In all matters of government, the correct answer is usually: Do nothing -- Robert Heinlein _Time Enough For Love_ p428 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Miriam Ruiz wrote: Why don't we all try to calm down and get less paranoid? I hope there are big Finnish saunas in Edinburgh. I think we all need to gather for a hot sauna next DebConf. We should change this you can't flame people you have had sauna with to you can't flame me until you've had sauna with me :) Most of us are nice people with just strong feelings about their ideas, but I guess it might be nice for all of us to learn how to empathyse and respect other's ideas, and think for a moment that other people might also good reasons for them, as not everything is black or white. What I do as an exercise in order to improve the skills you mention, empathy, respect, the feel of pleasure from working with others, is to work with the people I sponsor. They provide manpower and skills I lack, they fix bugs I have no time to look at, while I learn from them as they learn from me. I make mistakes they forgive me for, they make mistakes I can help them fix. It is something I encourage you all to do. Take a sponsoree and be his/her mentor. It's good for the karma. -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Anthony Towns wrote: Please hold off on filing them for a few days, so I can add usertag-on-submit support to debbugs, so that it should be possible to automatically track this stuff, and easily avoid filing duplicate bugs if they're not fixed the next time bugs get filed. Thanks, AJ. That is just what I was about to ask for :) -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
[Don Armstrong] Well, once I wake up a bit, you'll be able to go: Package: foopkg User: username Usertags: fooblehtag,bartag [But it won't work for setting multiple users... to do that, you'll have to use control.] This is even better. Is there a web page documenting this new feature? I would like to point the debian-edu developers to it. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek [EMAIL PROTECTED] said: On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote: That's not correct. [serious, grave, and critical] are the release critical severities, though some release critical issues won't be fixed for any given release, due to either being not known about or understood (ie, not filed at all, or not given the appropriate severity or attention), or given a specific exemption by the release team (etch-ignore). So riddle me this: currently, policy states that violating a must or required directive in policy is a serious bug; which seems to fly in the face of the release process having appropriated the serious severity. Are we removing the policy that violations of policy requirements are serious bugs? Is there new guidance on what policy violation bug severities ought to be? Are such bugs to be filed under normal? Or important? My understanding, which seems to be flawed, was policy violations were taken seriously (heh), and policy violation meant to be ignored for a release were granted special dispensation (remained serious, but were exempt). If this is not the case, we should change the policy, and drop any reference to bug severities for packages violating policy. Personally, think that is not a good idea, since adherence to technical policy seems to be the underpinning of the high quality of implementation we always had, but perhaps my mileage has varied. When there are issues addressed in policy that are black-and-white where all violations of the policy requirement are definitely bugs, but not all such violations should be grounds for keeping a package out of a release, how do you suggest such rules should be handled in the normative language of policy, and how do you suggest that the related bugs be handled in the BTS? Gee. Don't we already have something very like this? These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] All critical and grave bugs are release critical, and most serious bugs too. Any serious but which is non RC is tagged RELEAE-ignore; and the ignore tag should only be set after consultation with the release managers. How should we distinguish this case from rules that are *generally* but not always an indication of a bug (policy's description of should), and from one-time exception grants by the release team (the current use of the -ignore tag)? No one ever indicated that violations of a policy should directive is release critical, or even serious. Are you suggesting we should make _any_ policy violation the same? Curently, violating a should policy directive means you get a normal severuty bug. The current handling sanctioned by the BTS admins seems an appropriate middle ground for distinguishing the cases that are most relevant to bug handling across releases. It muddies up the nice, clean distinction that has always been in out technical policy: a) MUST/REQUIRED violation: serious bug If ignored a1) not RC else a2) RC b) SHOULD violation normal bug c) MAY/SUGGESTED violation wishlist bug manoj -- If only you knew she loved you, you could face the uncertainty of whether you love her. 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]
Re: Bug mass filling
On Sat, 21 Oct 2006, Petter Reinholdtsen wrote: [Don Armstrong] Well, once I wake up a bit, you'll be able to go: Package: foopkg User: username Usertags: fooblehtag,bartag [But it won't work for setting multiple users... to do that, you'll have to use control.] This is even better. Is there a web page documenting this new feature? I would like to point the debian-edu developers to it. Documentation? What's that? It'll show up on http://www.debian.org/Bugs/Reporting once wml gets rebuilt. Don Armstrong -- The sheer ponderousness of the panel's opinion ... refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it--and is just as likely to succeed. -- Alex Kozinski in Silveira V Lockyer http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sat, Oct 21, 2006 at 03:40:28PM -0500, Manoj Srivastava wrote: Gee. Don't we already have something very like this? These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] Those classifications haven't been monitored or updated, so no, we don't. IIRC that changed pretty soon after woody's release, with the creation of a specific list of RC criteria maintained by the release team. The woody policy addenda [0], for instance, said: Bashisms generally aren't release-critical, even when they're in scripts marked #!/bin/sh. They may be release-critical if their breakage causes other problems that are release-critical if they ever happen. In contrast, policy still states: Thus, shell scripts specifying `/bin/sh' as interpreter should only use POSIX features. If a script requires non-POSIX features from the shell interpreter, the appropriate shell must be specified in the first line of the script (e.g., `#!/bin/bash') Is a bashism in a /bin/sh script a normal bug (should only use POSIX features), or a RC bug (the appropriate shell bust be specified)? It's much easier to work out by just looking at the rc_policy text file maintained by the RM team [1]. Cheers, aj [0] http://people.debian.org/~ajt/woody_policy_addenda.txt [1] http://release.debian.org/etch_rc_policy.txt signature.asc Description: Digital signature
Re: Bug mass filling
On Sun, 22 Oct 2006 09:28:54 +1000, Anthony Towns aj@azure.humbug.org.au said: On Sat, Oct 21, 2006 at 03:40:28PM -0500, Manoj Srivastava wrote: Gee. Don't we already have something very like this? These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] Those classifications haven't been monitored or updated, so no, we don't. Yes, we do. You seem to be conflating the severity and RC-ness of a bug -- bugs have severities, and the release team decides which bugs are RC or not. IIRC that changed pretty soon after woody's release, with the creation of a specific list of RC criteria maintained by the release team. The woody policy addenda [0], for instance, said: Bashisms generally aren't release-critical, even when they're in scripts marked #!/bin/sh. They may be release-critical if their breakage causes other problems that are release-critical if they ever happen. In contrast, policy still states: Thus, shell scripts specifying `/bin/sh' as interpreter should only use POSIX features. If a script requires non-POSIX features from the shell interpreter, the appropriate shell must be specified in the first line of the script (e.g., `#!/bin/bash') Is a bashism in a /bin/sh script a normal bug (should only use POSIX features), or a RC bug (the appropriate shell bust be specified)? It's much easier to work out by just looking at the rc_policy text file maintained by the RM team [1]. Neither. It is a non RC serious bug. manoj -- Quod erat demonstrandum. [Thus it is proven. For those who wondered WTF QED means.] 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]
Re: Bug mass filling
On Thu, 19 Oct 2006 18:49:09 +0100, Adam D Barratt [EMAIL PROTECTED] said: On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote: Tshepang Lekhonkhobe wrote: Doesn't policy violation warrant Critical severity? No, it only warrants the lowest RC severity, serious [0], unless the bug in addition makes the package or other software (mostly) unusable, causes data loss, or introduces a security hole. Even then, it's only serious if it violates the release policy [http://release.debian.org/etch_rc_policy.txt]. Hence the reason that No. A bug may be serious and yet not RC, as I understand it. manoj -- A hacker does for love what others would not do for money. 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]
Re: Bug mass filling
Why don't we all try to calm down and get less paranoid? I don't think anyone's trying to piss off anyone, so I think we should all try to take it less personal. We probably all have different priorities, different goals and different ideas on how to achieve them, and I don't think anyone's making proposals, asking questions or giving anwers with the purpose of making anyone feel bad, that would be too presumptuous to think. I'm lately seeing too many people getting so upset as to orphan their packages, leave the project, too many insults everywhere or getting paranoid about every single suggestion it is made. I think most of that is just caused by the nerves, and after the release everythink will calm down. Most of us are nice people with just strong feelings about their ideas, but I guess it might be nice for all of us to learn how to empathyse and respect other's ideas, and think for a moment that other people might also good reasons for them, as not everything is black or white. Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Fri, Oct 20, 2006 at 04:06:05AM -0500, Manoj Srivastava wrote: Even then, it's only serious if it violates the release policy [http://release.debian.org/etch_rc_policy.txt]. Hence the reason that No. A bug may be serious and yet not RC, as I understand it. That's not correct. [serious, grave, and critical] are the release critical severities, though some release critical issues won't be fixed for any given release, due to either being not known about or understood (ie, not filed at all, or not given the appropriate severity or attention), or given a specific exemption by the release team (etch-ignore). Cheers, aj signature.asc Description: Digital signature
Re: Bug mass filling
On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote: Maybe some errors (E:) of lintian could be changed to critical (C:) and uploads containing such critical errors be refused by dak? What do you think? AFAIK dak doesn't support this? Does C: exist? Among all of the bugs reported by lintian, one concerns a lot of packages, the presence of the clean, binary, binary-arch, binary-indep and build targets. This is required by both the section 4.9 of the policy and the Etch release standards [1]. Here is the list of affected packages. What to do with them? Please hold off on filing them for a few days, so I can add usertag-on-submit support to debbugs, so that it should be possible to automatically track this stuff, and easily avoid filing duplicate bugs if they're not fixed the next time bugs get filed. Cheers, aj signature.asc Description: Digital signature
Re: Bug mass filling
Anthony Towns a écrit : On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote: Maybe some errors (E:) of lintian could be changed to critical (C:) and uploads containing such critical errors be refused by dak? What do you think? AFAIK dak doesn't support this? Does C: exist? No AFAIK dak doesn't support that. It was actually a suggestion, I don't know if it is easy to add. C: also does not exists, but it's really easy to implement in lintian. Anyway which bugs are errors (E:) or critical (C:) has to be decided in accordance with the release team. My idea with an automated test at upload is that we can use the time used to find such policy violations to find more complex bugs, and therefore improve the quality of the distribution. Among all of the bugs reported by lintian, one concerns a lot of packages, the presence of the clean, binary, binary-arch, binary-indep and build targets. This is required by both the section 4.9 of the policy and the Etch release standards [1]. Here is the list of affected packages. What to do with them? Please hold off on filing them for a few days, so I can add usertag-on-submit support to debbugs, so that it should be possible to automatically track this stuff, and easily avoid filing duplicate bugs if they're not fixed the next time bugs get filed. Ok, please let me know when it's ready. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Aurelien Jarno ([EMAIL PROTECTED]) [061021 00:37]: Anthony Towns a écrit : On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote: Maybe some errors (E:) of lintian could be changed to critical (C:) and uploads containing such critical errors be refused by dak? What do you think? AFAIK dak doesn't support this? Does C: exist? No AFAIK dak doesn't support that. It was actually a suggestion, I don't know if it is easy to add. C: also does not exists, but it's really easy to implement in lintian. Anyway which bugs are errors (E:) or critical (C:) has to be decided in accordance with the release team. My idea with an automated test at upload is that we can use the time used to find such policy violations to find more complex bugs, and therefore improve the quality of the distribution. That sounds like a worthwhile idea to me - one of the first things we should do post-etch probably. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sat, 21 Oct 2006 06:27:24 +1000, Anthony Towns aj@azure.humbug.org.au said: On Fri, Oct 20, 2006 at 04:06:05AM -0500, Manoj Srivastava wrote: Even then, it's only serious if it violates the release policy [http://release.debian.org/etch_rc_policy.txt]. Hence the reason that No. A bug may be serious and yet not RC, as I understand it. That's not correct. [serious, grave, and critical] are the release critical severities, though some release critical issues won't be fixed for any given release, due to either being not known about or understood (ie, not filed at all, or not given the appropriate severity or attention), or given a specific exemption by the release team (etch-ignore). So riddle me this: currently, policy states that violating a must or required directive in policy is a serious bug; which seems to fly in the face of the release process having appropriated the serious severity. Are we removing the policy that violations of policy requirements are serious bugs? Is there new guidance on what policy violation bug severities ought to be? Are such bugs to be filed under normal? Or important? My understanding, which seems to be flawed, was policy violations were taken seriously (heh), and policy violation meant to be ignored for a release were granted special dispensation (remained serious, but were exempt). If this is not the case, we should change the policy, and drop any reference to bug severities for packages violating policy. Personally, think that is not a good idea, since adherence to technical policy seems to be the underpinning of the high quality of implementation we always had, but perhaps my mileage has varied. manoj -- The happiest time of a person's life is after his first divorce. J.K. Galbraith 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]
Re: Bug mass filling
On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote: That's not correct. [serious, grave, and critical] are the release critical severities, though some release critical issues won't be fixed for any given release, due to either being not known about or understood (ie, not filed at all, or not given the appropriate severity or attention), or given a specific exemption by the release team (etch-ignore). So riddle me this: currently, policy states that violating a must or required directive in policy is a serious bug; which seems to fly in the face of the release process having appropriated the serious severity. Are we removing the policy that violations of policy requirements are serious bugs? Is there new guidance on what policy violation bug severities ought to be? Are such bugs to be filed under normal? Or important? My understanding, which seems to be flawed, was policy violations were taken seriously (heh), and policy violation meant to be ignored for a release were granted special dispensation (remained serious, but were exempt). If this is not the case, we should change the policy, and drop any reference to bug severities for packages violating policy. Personally, think that is not a good idea, since adherence to technical policy seems to be the underpinning of the high quality of implementation we always had, but perhaps my mileage has varied. When there are issues addressed in policy that are black-and-white where all violations of the policy requirement are definitely bugs, but not all such violations should be grounds for keeping a package out of a release, how do you suggest such rules should be handled in the normative language of policy, and how do you suggest that the related bugs be handled in the BTS? How should we distinguish this case from rules that are *generally* but not always an indication of a bug (policy's description of should), and from one-time exception grants by the release team (the current use of the -ignore tag)? The current handling sanctioned by the BTS admins seems an appropriate middle ground for distinguishing the cases that are most relevant to bug handling across releases. -- 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]
Re: Bug mass filling
On Fri, Oct 20, 2006 at 05:18:41PM -0700, Steve Langasek wrote: On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote: That's not correct. [serious, grave, and critical] are the release critical severities, though some release critical issues won't be fixed for any given release, due to either being not known about or understood (ie, not filed at all, or not given the appropriate severity or attention), or given a specific exemption by the release team (etch-ignore). So riddle me this: currently, policy states that violating a must or required directive in policy is a serious bug; which seems to fly in the face of the release process having appropriated the serious severity. Are we removing the policy that violations of policy requirements are serious bugs? Is there new guidance on what policy violation bug severities ought to be? Are such bugs to be filed under normal? Or important? My understanding, which seems to be flawed, was policy violations were taken seriously (heh), and policy violation meant to be ignored for a release were granted special dispensation (remained serious, but were exempt). If this is not the case, we should change the policy, and drop any reference to bug severities for packages violating policy. Personally, think that is not a good idea, since adherence to technical policy seems to be the underpinning of the high quality of implementation we always had, but perhaps my mileage has varied. When there are issues addressed in policy that are black-and-white where all violations of the policy requirement are definitely bugs, but not all such violations should be grounds for keeping a package out of a release, how do you suggest such rules should be handled in the normative language of policy, and how do you suggest that the related bugs be handled in the BTS? How should we distinguish this case from rules that are *generally* but not always an indication of a bug (policy's description of should), and from one-time exception grants by the release team (the current use of the -ignore tag)? The current handling sanctioned by the BTS admins seems an appropriate middle ground for distinguishing the cases that are most relevant to bug handling across releases. Hi Steve, One of Debian's principal attributes is openness, as with all FLOSS projects. With each release, would it useful to have, in addition to the Release notes, a _document_ like this: $RELEASE_NAME-ignore list: === PACKAGE|BUG NUMBER|BUG DESCIPTION |REASON FOR IGNORING ISSUE[|OPTIONAL_NAME|OPTIONAL_DATE] foo| 1234 | deletes db on mips | no one uses it on mips | joe RM | 01-01-1969 foo| 1234 | deletes db on mips | happens only on sundays | jane RM | 01-02-1969 === so that users, sysadmin and such could see what issue may affect them. Similarly, this document could _first_ be started as a _wiki page_ which could be generated from the current BTS info and during the release the RM's could have a location where they can state their reasons and then the package maintainer can have a centralized place for this info and an easy way to see and comment upon it. Because it seems that release issues between package maintainers and release managers happens in various place and have conflicting or subtly different answers depending upon person asked, when asked, etc. So a solid single point of update would seem to at least address some of this so that if 2 people or RM's give what seems to be confusing or contradictory info, it would have a single place to reference, where this would be easily seen by all involved. happy cat hurding, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Bug mass filling
Hi all, I have just run lintian on all the archive (amd64) for both binaries and sources, and the results are a bit scary. It looks like a lot of maintainers are uploading their packages, and don't really care with the policy. Maybe some errors (E:) of lintian could be changed to critical (C:) and uploads containing such critical errors be refused by dak? What do you think? Among all of the bugs reported by lintian, one concerns a lot of packages, the presence of the clean, binary, binary-arch, binary-indep and build targets. This is required by both the section 4.9 of the policy and the Etch release standards [1]. Here is the list of affected packages. What to do with them? E: adeos source: debian-rules-missing-required-target binary-indep E: ale source: debian-rules-missing-required-target binary-indep E: arabtex source: debian-rules-missing-required-target binary-arch E: autoconf source: debian-rules-missing-required-target binary-arch E: babygimp source: debian-rules-missing-required-target binary-arch E: backupninja source: debian-rules-missing-required-target binary-arch E: bamboo source: debian-rules-missing-required-target binary-arch E: bastille source: debian-rules-missing-required-target binary-indep E: bazaar-doc source: debian-rules-missing-required-target binary-indep E: bicyclerepair source: debian-rules-missing-required-target binary-arch E: bitlbee source: debian-rules-missing-required-target binary-indep E: blootbot source: debian-rules-missing-required-target binary-arch E: blootbot source: debian-rules-missing-required-target binary-indep E: boost-build source: debian-rules-missing-required-target binary-arch E: boost-build source: debian-rules-missing-required-target build E: bootcd source: debian-rules-missing-required-target binary-arch E: br2684ctl source: debian-rules-missing-required-target binary-indep E: c-cpp-reference source: debian-rules-missing-required-target build E: c2n source: debian-rules-missing-required-target binary-indep E: cacti source: debian-rules-missing-required-target binary-arch E: camlidl-doc source: debian-rules-missing-required-target binary-arch E: cassbeam source: debian-rules-missing-required-target binary-indep E: check source: debian-rules-missing-required-target binary-indep E: cli-common source: debian-rules-missing-required-target binary-arch E: clips-doc source: debian-rules-missing-required-target build E: coco-cs source: debian-rules-missing-required-target binary-arch E: coco-doc source: debian-rules-missing-required-target binary-arch E: coco-doc source: debian-rules-missing-required-target build E: coco-doc source: debian-rules-missing-required-target clean E: coco-java source: debian-rules-missing-required-target binary-arch E: configure-debian source: debian-rules-missing-required-target binary-arch E: cthumb source: debian-rules-missing-required-target build E: dag2html source: debian-rules-missing-required-target binary-indep E: db4.2 source: debian-rules-missing-required-target binary-indep E: debget source: debian-rules-missing-required-target binary-arch E: debroster source: debian-rules-missing-required-target binary-arch E: dhcp source: debian-rules-missing-required-target binary-indep E: dpkg-ftp source: debian-rules-missing-required-target build E: drbdlinks source: debian-rules-missing-required-target binary-arch E: drgeo-doc source: debian-rules-missing-required-target binary-arch E: dupload source: debian-rules-missing-required-target binary-arch E: dvipng source: debian-rules-missing-required-target binary-indep E: e00compr source: debian-rules-missing-required-target binary-indep E: efp source: debian-rules-missing-required-target binary-arch E: emms source: debian-rules-missing-required-target binary-indep E: enigmail source: debian-rules-missing-required-target build E: fapg source: debian-rules-missing-required-target binary-indep E: fbpanel source: debian-rules-missing-required-target binary-indep E: filler source: debian-rules-missing-required-target binary-arch E: flawfinder source: debian-rules-missing-required-target binary-arch E: flowscan source: debian-rules-missing-required-target binary-arch E: fortunes-ga source: debian-rules-missing-required-target binary-arch E: fortunes-it source: debian-rules-missing-required-target binary-arch E: freeswan source: debian-rules-missing-required-target binary-arch E: freetype1 source: debian-rules-missing-required-target binary-indep E: fv source: debian-rules-missing-required-target binary-indep E: gap-ctbllib source: debian-rules-missing-required-target binary-arch E: gap-matrix-schreiersims source: debian-rules-missing-required-target binary-arch E: gkrellmitime source: debian-rules-missing-required-target binary-indep E: gkrellweather source: debian-rules-missing-required-target binary-indep E: gnoise source: debian-rules-missing-required-target binary-indep E: gnome-lokkit source: debian-rules-missing-required-target binary-indep E: gnucap source:
Re: Bug mass filling
[Aurelien Jarno] I have just run lintian on all the archive (amd64) for both binaries and sources, and the results are a bit scary. It looks like a lot of maintainers are uploading their packages, and don't really care with the policy. What is the technical problem triggered by the packages with this lintian message? Is the autobuilders able to build these packages? If the autobuilders fail, I recommend you report that as a important or serious problem, and it it isn't, I recommend you report it as a normal bug. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On 10/19/06, Petter Reinholdtsen [EMAIL PROTECTED] wrote: [Aurelien Jarno] I have just run lintian on all the archive (amd64) for both binaries and sources, and the results are a bit scary. It looks like a lot of maintainers are uploading their packages, and don't really care with the policy. What is the technical problem triggered by the packages with this lintian message? Is the autobuilders able to build these packages? If the autobuilders fail, I recommend you report that as a important or serious problem, and it it isn't, I recommend you report it as a normal bug. Doesn't policy violation warrant Critical severity? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
[Tshepang Lekhonkhobe] Doesn't policy violation warrant Critical severity? Well, policy isn't a stick to beat other maintainers with, it is a tool to make sure our packages are well integrated and work properly. Thus, policy issues are not problems by themselves, they are policy issues because they might cause problems. And in this case, I am not sure what the exact problem caused by the lack of the binary-indep target is, so I ask. If no problem is caused by it, I believe 'normal' or even 'wishlist' severity is the proper severity to use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Tshepang Lekhonkhobe wrote: Doesn't policy violation warrant Critical severity? No, it only warrants the lowest RC severity, serious [0], unless the bug in addition makes the package or other software (mostly) unusable, causes data loss, or introduces a security hole. [0] http://www.debian.org/Bugs/Developer#severities regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote: If no problem is caused by it, I believe 'normal' or even 'wishlist' severity is the proper severity to use. s/wishlist/minor/ It _is_ a bug after all. pgp8CuxfBlHbn.pgp Description: PGP signature
Re: Bug mass filling
On Thu, Oct 19, 2006 at 06:45:53PM +0200, Petter Reinholdtsen wrote: Well, policy isn't a stick to beat other maintainers with, it is a tool to make sure our packages are well integrated and work properly. Thus, policy issues are not problems by themselves, they are policy issues because they might cause problems. And in this case, I am not sure what the exact problem caused by the lack of the binary-indep target is, so I ask. If no problem is caused by it, I believe 'normal' or even 'wishlist' severity is the proper severity to use. If there's no problem, change the policy. -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: Bug mass filling
* Tshepang Lekhonkhobe ([EMAIL PROTECTED]) [061019 18:09]: On 10/19/06, Petter Reinholdtsen [EMAIL PROTECTED] wrote: [Aurelien Jarno] I have just run lintian on all the archive (amd64) for both binaries and sources, and the results are a bit scary. It looks like a lot of maintainers are uploading their packages, and don't really care with the policy. What is the technical problem triggered by the packages with this lintian message? Is the autobuilders able to build these packages? If the autobuilders fail, I recommend you report that as a important or serious problem, and it it isn't, I recommend you report it as a normal bug. Doesn't policy violation warrant Critical severity? No. Please see the top of http://release.debian.org/etch_rc_policy.txt for which bugs are critical, grave and serious. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Aurelien Jarno ([EMAIL PROTECTED]) [061019 15:06]: Among all of the bugs reported by lintian, one concerns a lot of packages, the presence of the clean, binary, binary-arch, binary-indep and build targets. This is required by both the section 4.9 of the policy and the Etch release standards [1]. Here is the list of affected packages. What to do with them? If the bug also affects our autobuilders (especially the package has binary-any-packages), serious. Otherwise, important severity. If a package is totally broken (which might be in this case), serious might also be ok - but that needs to be decided on a case-by-case-basis. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: Doesn't policy violation warrant Critical severity? No. Please see the top of http://release.debian.org/etch_rc_policy.txt for which bugs are critical, grave and serious. That is irrelevant for the severity of bugs. This is the relevant definition: serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive) And in our case, the policy says: Both the binary-arch and binary-indep targets must exist. Don't change severities for releasing-in-time purposes. There is etch-ignore for that. Mike, wondering how many RC bugs will be tagged etch-ignore to reach the 80 bugs before freeze. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 07:01:20PM +0200, Frans Pop wrote: On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote: If no problem is caused by it, I believe 'normal' or even 'wishlist' severity is the proper severity to use. s/wishlist/minor/ It _is_ a bug after all. s/minor/important/, which is the severity used for policy violations that don't qualify as release-critical. And in this case, yes, the bugs should be filed as important rather than serious; the etch RC policy claims they should be serious, but it also does this in the section on autobuilding -- if no one has found any problems autobuilding these packages before now, despite multiple full-archive rebuilds over the past year, then it's a bug in the etch RC policy to suggest that these should be RC when they don't cause practical problems. -- 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]
Re: Bug mass filling
On Thu, 2006-10-19 at 19:51 +0200, Mike Hommey wrote: On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: Doesn't policy violation warrant Critical severity? No. Please see the top of http://release.debian.org/etch_rc_policy.txt for which bugs are critical, grave and serious. That is irrelevant for the severity of bugs. [...] Don't change severities for releasing-in-time purposes. There is Erm... the release team have been the arbiters of what merits an RC severity since at least before Sarge was released. From http://www.debian.org/Bugs/Developer#severities: Certain severities are considered release-critical, meaning the bug will have an impact on releasing the package with the stable release of Debian. Currently, these are critical, grave and serious. For complete and canonical rules on what issues merit these severities, see the list of Release-Critical Issues for Etch. The top of the latter page reads The purpose of this document is to be a correct, complete and canonical list of issues that merit a serious bug under the clause a severe violation of Debian policy. In addition to the issues listed in this document, an issue is release critical if it: [...] * in the maintainer's opinion, makes the package unsuitable for release (these issues are serious severity) i.e. if it's not in the policy and doesn't meet the above definition, it's *not* severity serious or higher. I'd suggest reading http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277074;msg=72, in which a current member of [EMAIL PROTECTED] (and at the time an RM) confirms that a member of the ftp-master team was correct in stating the above. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote: Tshepang Lekhonkhobe wrote: Doesn't policy violation warrant Critical severity? No, it only warrants the lowest RC severity, serious [0], unless the bug in addition makes the package or other software (mostly) unusable, causes data loss, or introduces a security hole. Even then, it's only serious if it violates the release policy [http://release.debian.org/etch_rc_policy.txt]. Hence the reason that [0] http://www.debian.org/Bugs/Developer#severities says [...]roughly, it violates a must or required directive. The final word for what justifies a release-critical severity belongs to the release team (hence also the paragraph on rc-ness at the foot of the documentation). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 07:51:19PM +0200, Mike Hommey wrote: On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: Doesn't policy violation warrant Critical severity? No. Please see the top of http://release.debian.org/etch_rc_policy.txt for which bugs are critical, grave and serious. That is irrelevant for the severity of bugs. This is the relevant definition: serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive) That definition, as listed on http://www.us.debian.org/Bugs/Developer#severities, links straight to the release team's RC bug policy. -- 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]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 11:29:38AM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 07:51:19PM +0200, Mike Hommey wrote: On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: Doesn't policy violation warrant Critical severity? No. Please see the top of http://release.debian.org/etch_rc_policy.txt for which bugs are critical, grave and serious. That is irrelevant for the severity of bugs. This is the relevant definition: serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive) That definition, as listed on http://www.us.debian.org/Bugs/Developer#severities, links straight to the release team's RC bug policy. Note how subtly the Etch RC policy removes the first alternative of the serious bug description... Anyways, I've always thought the bts severity levels and release criticality were orthogonal things. i.e. it's more complicated than just saying critical, grave and serious levels are RC. There are important or even normal issues (as per definition of the severity levels) that are more release critical than serious (again, as per definition of the severity levels) bugs. But yet, violation of the Debian policy should be granted serious level. etch-ignore is here to make the issue not release critical. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: Note how subtly the Etch RC policy removes the first alternative of the serious bug description... Which do you mean? Please read the Etch RC policy. It tells: | In addition to the issues listed in this document, an issue is release | critical if it: | [...] | * in the maintainer's opinion, makes the package unsuitable | for release So, what does the Etch RC policy remove from the bugs.d.o description? Anyways, I've always thought the bts severity levels and release criticality were orthogonal things. i.e. it's more complicated than just saying critical, grave and serious levels are RC. That is wrong. There are important or even normal issues (as per definition of the severity levels) that are more release critical than serious (again, as per definition of the severity levels) bugs. Wrong. A bug is release-critical := the bug has severity serious, grave, critical and has not been given an excemption by the release team But yet, violation of the Debian policy should be granted serious level. etch-ignore is here to make the issue not release critical. Wrong. Etch-ignore is for exemptions for issues that otherwise match the definition of release critical on that page. It is not for normal sorting of issues. A violation of the parts of the debian policy as listed on http://release.debian.org/etch_rc_policy.txt is serious level (that should be the same as the must-directives in policy, but - well, I hope that I have finally time post-etch to sync that finally). Any other policy violation is at most important level (unless it conincides with one of the other criteria for RC bugs, of course). Cheers, Andi Debian Release Manager -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: Note how subtly the Etch RC policy removes the first alternative of the serious bug description... Which do you mean? Please read the Etch RC policy. It tells: | In addition to the issues listed in this document, an issue is release | critical if it: | [...] | * in the maintainer's opinion, makes the package unsuitable | for release So, what does the Etch RC policy remove from the bugs.d.o description? 'is a severe violation of Debian policy (roughly, it violates a must or required directive), or' Anyways, I've always thought the bts severity levels and release criticality were orthogonal things. i.e. it's more complicated than just saying critical, grave and serious levels are RC. That is wrong. There are important or even normal issues (as per definition of the severity levels) that are more release critical than serious (again, as per definition of the severity levels) bugs. Wrong. A bug is release-critical := the bug has severity serious, grave, critical and has not been given an excemption by the release team You may have missed the thought part of the sentence. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]: On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: Note how subtly the Etch RC policy removes the first alternative of the serious bug description... Which do you mean? Please read the Etch RC policy. It tells: | In addition to the issues listed in this document, an issue is release | critical if it: | [...] | * in the maintainer's opinion, makes the package unsuitable | for release So, what does the Etch RC policy remove from the bugs.d.o description? 'is a severe violation of Debian policy (roughly, it violates a must or required directive), or' The html-code for this part is: DTCODEserious/CODE DDis a a href=http://release.debian.org/etch_rc_policy.txt;severe violation of Debian policy/a (roughly, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. So, obviously http://www.debian.org/Bugs/Developer#severities defines that severe violation of Debian policy means anything referenced in the etch_rc_policy-document. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]: On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: Note how subtly the Etch RC policy removes the first alternative of the serious bug description... Which do you mean? Please read the Etch RC policy. It tells: | In addition to the issues listed in this document, an issue is release | critical if it: | [...] | * in the maintainer's opinion, makes the package unsuitable | for release So, what does the Etch RC policy remove from the bugs.d.o description? 'is a severe violation of Debian policy (roughly, it violates a must or required directive), or' The html-code for this part is: DTCODEserious/CODE DDis a a href=http://release.debian.org/etch_rc_policy.txt;severe violation of Debian policy/a (roughly, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. So, obviously http://www.debian.org/Bugs/Developer#severities defines that severe violation of Debian policy means anything referenced in the etch_rc_policy-document. Yeah, right, whatever, as soon as etch is release on December 4th... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Andreas Barth a écrit : A violation of the parts of the debian policy as listed on http://release.debian.org/etch_rc_policy.txt is serious level (that should be the same as the must-directives in policy, but - well, I hope that I have finally time post-etch to sync that finally). Any other policy violation is at most important level (unless it conincides with one of the other criteria for RC bugs, of course). Note that what we are discussing (must have in targets debian/rules) are listed on http://release.debian.org/etch_rc_policy.txt -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:25]: On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]: On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: Note how subtly the Etch RC policy removes the first alternative of the serious bug description... Which do you mean? Please read the Etch RC policy. It tells: | In addition to the issues listed in this document, an issue is release | critical if it: | [...] | * in the maintainer's opinion, makes the package unsuitable | for release So, what does the Etch RC policy remove from the bugs.d.o description? 'is a severe violation of Debian policy (roughly, it violates a must or required directive), or' The html-code for this part is: DTCODEserious/CODE DDis a a href=http://release.debian.org/etch_rc_policy.txt;severe violation of Debian policy/a (roughly, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. So, obviously http://www.debian.org/Bugs/Developer#severities defines that severe violation of Debian policy means anything referenced in the etch_rc_policy-document. Yeah, right, whatever, as soon as etch is release on December 4th... What do you intend to say by that? The definition of serious was already that way when I was looking at the release from the very outside, before I was a DD even (ok, it was sarge_rc_policy.txt, and not etch at that time). It has *nothing* whatsoever to do with the planned release date ... But I need to admit that I get sick, seriously sick. If someone doesn't agree with something, he just says you do it wrong just for release of etch on $date. I really hate that. Especially when it's about things that are done that way since ages, but someone just recently has become aware of that. That really takes the fun away from Debian for me. I don't know if that's what you intend, but that's what you achieve. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Andreas Barth ([EMAIL PROTECTED]) wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]: On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: Note how subtly the Etch RC policy removes the first alternative of the serious bug description... Which do you mean? Please read the Etch RC policy. It tells: | In addition to the issues listed in this document, an issue is release | critical if it: | [...] | * in the maintainer's opinion, makes the package unsuitable | for release So, what does the Etch RC policy remove from the bugs.d.o description? 'is a severe violation of Debian policy (roughly, it violates a must or required directive), or' The html-code for this part is: DTCODEserious/CODE DDis a a href=http://release.debian.org/etch_rc_policy.txt;severe violation of Debian policy/a (roughly, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. So, obviously http://www.debian.org/Bugs/Developer#severities defines that severe violation of Debian policy means anything referenced in the etch_rc_policy-document. I would have thought that meant a violation of http://www.us.debian.org/doc/debian-policy/. I certainly think it's the release manager's responsibility to mark bugs that are not release blocking etch-ignore, but if it is a violation of policy it should still be serious. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Bug mass filling
* Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]: Andreas Barth a écrit : A violation of the parts of the debian policy as listed on http://release.debian.org/etch_rc_policy.txt is serious level (that should be the same as the must-directives in policy, but - well, I hope that I have finally time post-etch to sync that finally). Any other policy violation is at most important level (unless it conincides with one of the other criteria for RC bugs, of course). Note that what we are discussing (must have in targets debian/rules) are listed on http://release.debian.org/etch_rc_policy.txt As vorlon said, that is listed under the heading of 4. Autobuilding, so the scope is buildds must not fail of this rule. That is why I asked to file the cases where buildds failed as serious, and the others as important (and cases where Packages in the archive must not be so buggy [...] we refuse to support them. as serious as well, that is under section 5. General). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 09:35:38PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: But I need to admit that I get sick, seriously sick. If someone doesn't agree with something, he just says you do it wrong just for release of etch on $date. I really hate that. Especially when it's about things that are done that way since ages, but someone just recently has become aware of that. I need to admit that I get sick, seriously sick of all that has been happening in Debian in the last couple of months, between RM funding, dunc-tank, people resigning, release date chosen on odd grounds, do whatever to release on that date, whatever, 42 stupid useless GRs to delay (again) what was delayed in order to release sarge, Sven Luther vs. Sven Luther's enemies, ... ... ... ... I'm not even talking about that stupid Mozilla® affair. That really takes the fun away from Debian for me. Same here. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 03:53:56PM -0400, Eric Dorland [EMAIL PROTECTED] wrote: * Andreas Barth ([EMAIL PROTECTED]) wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]: On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: Note how subtly the Etch RC policy removes the first alternative of the serious bug description... Which do you mean? Please read the Etch RC policy. It tells: | In addition to the issues listed in this document, an issue is release | critical if it: | [...] | * in the maintainer's opinion, makes the package unsuitable | for release So, what does the Etch RC policy remove from the bugs.d.o description? 'is a severe violation of Debian policy (roughly, it violates a must or required directive), or' The html-code for this part is: DTCODEserious/CODE DDis a a href=http://release.debian.org/etch_rc_policy.txt;severe violation of Debian policy/a (roughly, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. So, obviously http://www.debian.org/Bugs/Developer#severities defines that severe violation of Debian policy means anything referenced in the etch_rc_policy-document. I would have thought that meant a violation of http://www.us.debian.org/doc/debian-policy/. That was not a link before it was changed before sarge release, in July 2004. Interesting log in the web page cvs: The RM defines what the 'serious' severity means. jvw regarding -a and -o in -test, aj, Kamion and vorlon said on June 8 that it is not considered RC by you guys. Okay to tag bugs with '... uses XSIisms (test ... -a/-o ...) with sarge-ignore? aj jvw: no, it's not okay for them to be marked RC in the first place aj http://people.debian.org/~ajt/sarge_rc_policy.txt is the canonical place to look for the definition of severe policy violation aj sarge-ignore is not possible as it is not an RC issue [...] jvw aj: so you say http://www.debian.org/Bugs/Developer#severities is wrong? aj whatever jvw I'm not going to be able to convince people that http://www.debian.org/Bugs/Developer#severities is wrong, but I might be able to say it isn't a Sarge issue at least, but that involves sarge-ignore, which requires your okay aj it doesn't matter what that page says aj http://people.debian.org/~ajt/sarge_rc_policy.txt is canonical aj if the bug doesn't match the criteria on that page it's not serious grave or critical So, what is written on http://www.debian.org/Bugs/Developer#severities doesn't count (not to say it's crap), and it's not necessary to change it. By the way, reportbug doesn't give anything close to a hint that it could be anything else than than Debian Policy: 3 serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should not do so.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 09:56:37PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]: Andreas Barth a écrit : A violation of the parts of the debian policy as listed on http://release.debian.org/etch_rc_policy.txt is serious level (that should be the same as the must-directives in policy, but - well, I hope that I have finally time post-etch to sync that finally). Any other policy violation is at most important level (unless it conincides with one of the other criteria for RC bugs, of course). Note that what we are discussing (must have in targets debian/rules) are listed on http://release.debian.org/etch_rc_policy.txt As vorlon said, that is listed under the heading of 4. Autobuilding, so the scope is buildds must not fail of this rule. That is why I Where does it say the scope for 4. Autobuilding is buildds must not fail ? It does say Packages must autobuild without failure on all architectures on which they are supported, but that's one of the options that make a bug RC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]: That was not a link before it was changed before sarge release, in July 2004. The link was added later because people were barking around. The meaning was always the same. Anyways, July 2004 is a *bit* history now, don't you think so? So, what is written on http://www.debian.org/Bugs/Developer#severities doesn't count (not to say it's crap), and it's not necessary to change it. If you disagree with what is written on the page, you might want to ask [EMAIL PROTECTED] for clarification, or you could appeal to the Technical Committee, or you could ask the developers in a GR. Until you succeed at at least one of the ways, the definition as written down by a member of [EMAIL PROTECTED] stays valid. As it is always. Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]: Where does it say the scope for 4. Autobuilding is buildds must not fail ? There are always bugs in any document. For sarge, we e.g. sarge-ignored some MTAs which didn't provide -bs, though LSB requires that. Now, we adjusted the policy to make it legal (as long as they conflict with lsb of course). Nothing wrong with that, the text isn't written in stone. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 10:15:16PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]: That was not a link before it was changed before sarge release, in July 2004. The link was added later because people were barking around. The meaning was always the same. The meaning of Debian Policy was always something else than http://www.us.debian.org/doc/debian-policy/ ? Come on... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]: Where does it say the scope for 4. Autobuilding is buildds must not fail ? There are always bugs in any document. Be aware that, even if you don't like it, this looks like you bend the rules so that it doesn't alter the release plan. Be also aware that too much bending the rules makes them useless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]: [another agression] Sorry, but enough is enough. I'm fed up about your sudden agressions towards me for no reason at all. Welcome to my killfile. Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Mike Hommey [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]: Where does it say the scope for 4. Autobuilding is buildds must not fail ? There are always bugs in any document. Be aware that, even if you don't like it, this looks like you bend the rules so that it doesn't alter the release plan. Be also aware that too much bending the rules makes them useless. What about your proposing a GR to recall the Release Managers? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Bug mass filling
Mike Hommey [EMAIL PROTECTED] writes: So, what does the Etch RC policy remove from the bugs.d.o description? 'is a severe violation of Debian policy (roughly, it violates a must or required directive), or' Perhaps you should concentrate on the word roughly there. What constitutes a severe violation is in the judgment of the Release Team, and the release goals indicate their judgment in the context of a particular release. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
Mike Hommey [EMAIL PROTECTED] wrote: Be aware that, even if you don't like it, this looks like you bend the rules so that it doesn't alter the release plan. Be also aware that too much bending the rules makes them useless. Don't try to bend the rules, it's impossible. Instead, only realize the truth: there are no rules. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]: [another agression] Waw, actually, i was trying to be less aggressive... Anyways, since I'm too pissed and since I see no reason to put myself in that mood any further, I'm taking a few days off Debian, which means my current work on seamonkey^Hiceape will be on hold. All the work in progress on my currently maintained packages will be on hold too. If you want iceape in shape for etch if we are anything near a freeze, well, get your fingers out of your asses, as we say in french. Mike signature.asc Description: Digital signature
Re: Bug mass filling
On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]: [another agression] Sorry, but enough is enough. I'm fed up about your sudden agressions towards me for no reason at all. Welcome to my killfile. Hi Andi, from my perspective, I see this: DD's trying to use Debian policy as a guide to make all packages pass policy requirement. Is this not what they are tasked to do ? They see inconsistencies between RM's understanding of these and their goals. And they seem to say that if someone would alter, fix, change or clarify policy, they could have a clear goal for them to reach release targets. This way they would not be confused about the unclear judgments that they are reading from RM's and won't bother them for further questions that waste everyones time and patience. I dont see this as an attack on RM's, I see it as folks wanting help to reach release goals and want someone to just clarify policy. Now if nobody clarifies policy, they have to get guidance from the only people who can: RM's. If there is some reason why the RM's are not able/willing to do this, then that leads to only further frustration and no progress, as witnesses by this and other threads. So, if someone can just update, clarify, fix, or in someway address this, please lets focus on the real goal: liw's tattoo! have a nice day! cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Bug mass filling
On Thu, Oct 19, 2006 at 10:52:25PM +0200, Mike Hommey wrote: On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]: [another agression] Waw, actually, i was trying to be less aggressive... This is a very, very old argument, and it doesn't really come across to me as less aggressive to continue to suggest that the RMs are changing the rules to meet the release deadline, or even that it will *appear* that we are doing so, when these are rules that have governed the use of RC severities in the BTS for at least the past three years and are explicitly sanctioned by the BTS admins. So I'm sorry that this upsets you, but it's not exactly the release team's fault if people are inferring things from the BTS documentation that aren't written there. -- 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]
Re: Bug mass filling
On Thu, 19 Oct 2006, Kevin Mark wrote: DD's trying to use Debian policy as a guide to make all packages pass policy requirement. Is this not what they are tasked to do? There's nothing wrong with these goals. Indeed, I'm sure no one would object to patches and bugs being filed to fix these policy issues. The only question is whether the bugs are RC or not. The RMs have the ability to determine which policy issues are RC; the people who can override their decision (by making other bugs RC) are the maintainers for a particular package, by deciding that a particular package is not fit for release. Otherwise, when the RMs have clarified the release policy (as they have just done), then we should go back to fixing bugs instead of arguing about whether or not the bugs are really all that bad or not. Don Armstrong -- Il semble que la perfection soit atteinte non quand il n'y a plus rien a ajouter, mais quand il n'y a plus rien a retrancher. (Perfection is apparently not achieved when nothing more can be added, but when nothing else can be removed.) -- Antoine de Saint-Exupe'ry, Terres des Hommes http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On 10/19/06, Mike Hommey [EMAIL PROTECTED] wrote: Waw, actually, i was trying to be less aggressive... Anyways, since I'm too pissed and since I see no reason to put myself in that mood any further, I'm taking a few days off Debian, which means my current work on seamonkey^Hiceape will be on hold. All the work in progress on my currently maintained packages will be on hold too. If you want iceape in shape for etch if we are anything near a freeze, well, get your fingers out of your asses, as we say in french. I would take it out if it was in there, but please don't be pissed off so soon. Continue hacking away and let's have the best release ever :-) I really want to see Seamonkey in Etch, and you even asked the RM's to allow you to upload it (version 1.1) when released later this month. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
