Re: [gentoo-dev] Re: robo-stable bugs
On Thu, 23 May 2013 23:40:42 -0600 Ryan Hill dirtye...@gentoo.org wrote: Okay, so what are you using the STABLEREQ keyword for that you want to set it when the bug is filed but before archs are added? If you want to see only stabilization bugs you can search in the Keywording and Stabilization component. Can you suggest another way to search for stabilization bugs that don't yet have archs CC'd (which is something I find rather useful)? We could split up [Keywording and Stabilization] into separate components, [Keywording] and [Stabilization], but then 1) people would still forget to set it, at whatever stage, and 2) this wouldn't fit with [Security]/[Vulnerabilities]. It's important to be able to distinguish between STABLEREQ and KEYWORDREQ. I think a KEYWORDREQ should normally be handled earlier than any STABLEREQ /unless/ the STABLEREQ fixes a security bug, since being late getting keywords back up to par with other architectures tends to make an even bigger mess further on. Alternatively, we could set CONFIRMED or IN_PROGRESS when a) the Component is [Keywording and Stabilization] and b) arch teams are CC'd, but then everyone would forget to set that half the time, too. jer
Re: [gentoo-dev] Re: robo-stable bugs
On Thu, 23 May 2013 23:40:42 -0600 Ryan Hill dirtye...@gentoo.org wrote: Okay, so what are you using the STABLEREQ keyword for that you want to set it when the bug is filed but before archs are added? The people that decided to change their way of using this keyword, did so because setting it as early as possible helps maintainers that forget to set it; I'm just following along this new approach. If you want to see only stabilization bugs you can search in the Keywording and Stabilization component. Yet, they brought this keyword to live for a reason; a reason unclear to me. Why is it unclear? Because nowadays people don't use it consistently; some apply it early, some apply it when they CC. Can you suggest another way to search for stabilization bugs that don't yet have archs CC'd (which is something I find rather useful)? Setting the keyword early helps here too, if everyone does so. Otherwise you can do ... 1) a search in Keywording and Stabilization and exclude all bugs where an arch is CC-ed, possible in the advanced search; or ... 2) obsessive summary grepping, for bugs with a wrong component set. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
Jeroen Roovers posted on Wed, 22 May 2013 17:21:46 +0200 as excerpted: On Tue, 21 May 2013 00:46:22 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: As a user, I've understood: * Severity is something the user/filer can use. So when Chromium doesn't compile on your machine, you set it as a Blocker, and then it gets reverted to Normal because it works fine for the other 99,9%. Well, I chose to put the big bullet-points at the top and the caveats (with which you agreed) below. The caveat in this case being that even still a normal user shouldn't be setting it, and I even proposed making that the first level of gentoo bugzilla privilege people could get, thus restricting it for the general user. Individual users are probably not best suited to discover the scope of a bug report, let alone the actual bug, if there is one. If the Severity does not get reverted to Normal, then we can safely assume it's being completely ignored. I'd not agree that it's safe to assume, but it certainly could be the case. The interpretation of Severity is highly dependent on the type of bug report. It's already diverting strongly between stabilisation requests, security vulnerabilities and changes to documentation. The meaning of the field thusly changes according to the Product/Component and other fields. True. Even so, if there's no known-approved reason to set severity, a user should just leave it alone. That means users unfamiliar with gentoo's bugzilla should just leave it alone. Agreed. =:^) * If it's an enhancement I mark it as such, and expect maintainer bug priority ranked less urgent as a result. The *.desktop file example someone mentioned goes here, What if a bad/missing .desktop file stops you from running an app through your DM/another app trying to find an appropriate program to open a file in? It's still an enhancement. If it were /that/ important to the app in general, it'd be shipped by upstream. It not being shipped by upstream means (at minimum) they don't care enough to have made it a priority, and that existing general functionality isn't affected, which means the generally lower priority of enhancement fits, because that's what it /is/, an enhancement, an /added/ feature in this case for better desktop integration. It's certainly more an enhancement than a bug with an existing feature, the default case, thus the name bugzilla. * If the bug has system-wide or arch-class-wide (all ~arch, for instance) implications, I'll sometimes up severity accordingly, with a note in the text explaining my reasoning. Toolchain or base-system bugs that prevent normal boot or system upgrade arguably fit here, especially if they're on a recently (say a day) unmasked or announced to be unmasked package with arch-class-wide implications, where an immediate remask might be appropriate until the situation can be resolved. What if your initial analysis completely misses the mark? Then you end up with an INVALID Blocker with one or more devs investigating hours in a user error. How did setting Severity help here? In the first privilege scenario I suggested, ordinary users wouldn't have that ability, and if those who /do/ have that ability abuse it consistently, well, it's a privilege not a right, and it gets revoked as such. Which would tend to make users with the privilege /very/ cautious about setting it, since it could cause a privilege revoke. In conclusion, setting Severity can only be properly done after an actual bug has been appreciated, not at the time you file the bug report. With the bugs I file where I change it, I've confident enough in the leg- work I've already done to know the _severity_ of the bug -- basically, a rough percentage of package users that would face the bug were they to emerge that version of the package right now, and the effect it would have on their system. If anything, I tend to under-rank the severity. An example of a blocker bug would be the one a few years ago where portage was screwing up glibc symlinks, pretty much killing the entire system for anyone that tried that (freshly unmasked IIRC) version! (In that case it was a portage symlinking bug... that happened to occur at exactly the worst time possible, at almost exactly the same time a new glibc came out, triggering the bug in the worst possible way.) Similarly, the IIRC twice in nearing a decade on gentoo I've seen a bash bug (in ~arch, admittedly, where they're to expected from time to time and people running ~arch should be prepared to deal with it) that effectively killed the default system shell... for anyone happening to update to it on ~arch since that's where it was unmasked. As explained above, the security team has its own rules. Basically what I was saying, they're handled separately (my words) and have their own rules (yours). -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master --
[gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 13:00:46 +0200 Tom Wijsman tom...@gentoo.org wrote: On Wed, 22 May 2013 11:07:26 +0200 Ulrich Mueller u...@gentoo.org wrote: Is a stabilisation an enhancement per se? If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. Do you agree that a version bump, i.e. an ebuild entering ~arch is an enhancement? Then why would it be different if the same ebuild gets promoted from ~arch to arch? Is a version bump an enhancement per se? Yes. Nothing is broken. There is no bug to fix. If all version bumps are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced version bump to begin with, Mozilla?) It's not an enhanced bug, the bug is a request for an improvement (aka enhance_ment_). Severity is meant to give you a way of categorizing open bugs by how important they are, as you may want to fix actual bugs before worrying about adding features. Maybe you don't use bugzilla like that but some people do and lumping these bugs in with the normal ones prevents them from doing so. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: robo-stable bugs
On Thu, 23 May 2013 23:20:00 -0600 Ryan Hill dirtye...@gentoo.org wrote: Is a version bump an enhancement per se? Yes. Nothing is broken. There is no bug to fix. No. Things can be broken. There are almost always bugs to fix. New versions come with bug fixes too, users need these fixes. If all version bumps are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced version bump to begin with, Mozilla?) It's not an enhanced bug, the bug is a request for an improvement (aka enhance_ment_). Bug fixes are improvements too, so this definition is ambiguous. Severity is meant to give you a way of categorizing open bugs by how important they are, as you may want to fix actual bugs before worrying about adding features. Version bumps do not necessarily add features; just because they have the potential to add features doesn't mean they don't fix actual bugs. Maybe you don't use bugzilla like that but some people do and lumping these bugs in with the normal ones prevents them from doing so. Using enhancement prevents them from importing upstream bug fixes. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 10:58:26 +0200 Tom Wijsman tom...@gentoo.org wrote: On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill dirtye...@gentoo.org wrote: Also, your script does not set the STABLEREQ keyword. People are having to hunt down your robo-stabilisation requests and add it themselves. You should just do it yourself or turn your script off. Did you read the message? The point is you're supposed to add that yourself. It's not a STABLEREQ until you add arches. Yet the base system lead went and apply it to any stabilization bug; as both him and Jer (the bug wrangling lead) do it this way, I'll be doing it as well. Let's not be inconsistent with our leads unless there is a wide decision to do so Okay, so what are you using the STABLEREQ keyword for that you want to set it when the bug is filed but before archs are added? If you want to see only stabilization bugs you can search in the Keywording and Stabilization component. Can you suggest another way to search for stabilization bugs that don't yet have archs CC'd (which is something I find rather useful)? -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: robo-stable bugs
On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill dirtye...@gentoo.org wrote: Huh? The severity of the bug is it's an enhancement. Yes stabilizations are enhancements. Always have been. Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. Also, your script does not set the STABLEREQ keyword. People are having to hunt down your robo-stabilisation requests and add it themselves. You should just do it yourself or turn your script off. Did you read the message? The point is you're supposed to add that yourself. It's not a STABLEREQ until you add arches. Yet the base system lead went and apply it to any stabilization bug; as both him and Jer (the bug wrangling lead) do it this way, I'll be doing it as well. Let's not be inconsistent with our leads unless there is a wide decision to do so; I expect none will come, unless you really think this should become Council material. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013, Tom Wijsman wrote: On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill dirtye...@gentoo.org wrote: Huh? The severity of the bug is it's an enhancement. Yes stabilizations are enhancements. Always have been. Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. Do you agree that a version bump, i.e. an ebuild entering ~arch is an enhancement? Then why would it be different if the same ebuild gets promoted from ~arch to arch? Ulrich
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 18:58, Tom Wijsman wrote: On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill dirtye...@gentoo.org wrote: Huh? The severity of the bug is it's an enhancement. Yes stabilizations are enhancements. Always have been. Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. A newer version of a package is usually considered to be better in some way, hence it is an enhancement. Also, your script does not set the STABLEREQ keyword. People are having to hunt down your robo-stabilisation requests and add it themselves. You should just do it yourself or turn your script off. Did you read the message? The point is you're supposed to add that yourself. It's not a STABLEREQ until you add arches. Yet the base system lead went and apply it to any stabilization bug; as both him and Jer (the bug wrangling lead) do it this way, I'll be doing it as well. Let's not be inconsistent with our leads unless there is a wide decision to do so; I expect none will come, unless you really think this should become Council material. According to the bug-wrangler's own docs[1]: A stabilisation request should be handled by the package's maintainer, so you should not CC arch teams in your role as bug wrangler, nor set the STABLEREQ keyword in the Keywords field.. There should at least be some consistency there before telling people what to do. As for base system, I don't really see what bearing their actions has to do with anything to on bugzilla. (And let's not forget that the current lead has a history of doing whatever he wants, so I don't think the actions that come out of that are a good example to follow). [1]: http://www.gentoo.org/proj/en/qa/bug-wranglers/
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand.
Re: [gentoo-dev] Re: robo-stable bugs
On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone.
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. I am confused as to what you are proposing. Do you want arch teams to continually test packages that are already in stable to make sure they haven't broken somehow?
Re: [gentoo-dev] Re: robo-stable bugs
Michael Palimaka schrieb: On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. I am confused as to what you are proposing. Do you want arch teams to continually test packages that are already in stable to make sure they haven't broken somehow? The point is probably, that when you stable a package with inactive maintainer, there will be noone following the opened bugs against this new version. So this looks like a case, where one should ask for a new maintainer, who then decides about the stable versions instead of doing auto-stabilization. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 11:07:26 +0200 Ulrich Mueller u...@gentoo.org wrote: Is a stabilisation an enhancement per se? If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. Do you agree that a version bump, i.e. an ebuild entering ~arch is an enhancement? Then why would it be different if the same ebuild gets promoted from ~arch to arch? Is a version bump an enhancement per se? If all version bumps are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced version bump to begin with, Mozilla?) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 20:41, Thomas Sachau wrote: Michael Palimaka schrieb: On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. I am confused as to what you are proposing. Do you want arch teams to continually test packages that are already in stable to make sure they haven't broken somehow? The point is probably, that when you stable a package with inactive maintainer, there will be noone following the opened bugs against this new version. So this looks like a case, where one should ask for a new maintainer, who then decides about the stable versions instead of doing auto-stabilization. If the maintainer is inactive, presumably nobody is looking at bugs for the old version either.
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 21:00, Tom Wijsman wrote: On Wed, 22 May 2013 11:07:26 +0200 Ulrich Mueller u...@gentoo.org wrote: Is a stabilisation an enhancement per se? If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. Do you agree that a version bump, i.e. an ebuild entering ~arch is an enhancement? Then why would it be different if the same ebuild gets promoted from ~arch to arch? Is a version bump an enhancement per se? If all version bumps are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced version bump to begin with, Mozilla?) What does this statement even mean?
Re: [gentoo-dev] Re: robo-stable bugs
On 05/22/13 13:06, Michael Palimaka wrote: On 22/05/2013 20:41, Thomas Sachau wrote: Michael Palimaka schrieb: On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. I am confused as to what you are proposing. Do you want arch teams to continually test packages that are already in stable to make sure they haven't broken somehow? The point is probably, that when you stable a package with inactive maintainer, there will be noone following the opened bugs against this new version. So this looks like a case, where one should ask for a new maintainer, who then decides about the stable versions instead of doing auto-stabilization. If the maintainer is inactive, presumably nobody is looking at bugs for the old version either. And the circle is closed since we started with the correlation no answer to stable bug in 30 days = package unmantained ;-)
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 21:07:45 +1000 Michael Palimaka kensing...@gentoo.org wrote: Is a stabilisation an enhancement per se? If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. Do you agree that a version bump, i.e. an ebuild entering ~arch is an enhancement? Then why would it be different if the same ebuild gets promoted from ~arch to arch? Is a version bump an enhancement per se? If all version bumps are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced version bump to begin with, Mozilla?) What does this statement even mean? It means the same as it meant the first time. Let me ask you the same: What does enhancement even mean? Isn't any bug an enhancement? What is enhancement in the meaning of severity? Who makes up this meaning? Why? How does enhancement instead of normal as a severity help us? Just setting things because we can set them is silly and a time waste... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 06:07 AM, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. Unless it's officially maintainer-needed, a package shouldn't be in ~arch when it's unmaintained, either. If an AT passes a package from ~arch to stable, it's no more likely to break things there than it is in ~arch. Plus, it's important to consider the zero-bugs case here -- if all bugs in the ~arch package are fixed, AND the ATs give it a go, then the likliness of harm in stable is pretty minimal. I'd say less so than the end-users keywording the package. Now, one big thing I do worry about with this whole process, is that it's going to significantly increase the workload on ATs. And if it does that, what's the likliness of things getting a 'pass' when they shouldn't? *that* part I worry about more, when the maintainer hasn't manually cleared a package for stabilization. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGcweYACgkQ2ugaI38ACPDGmAD/QtIKe/J5Xg3TjthITn1eTLA4 NfSMrrF6cyXfOdjtmoABAKauw9JDDX5JjUERL2K8At88VjWfeeST45qZ9HifDanv =qB7D -END PGP SIGNATURE-
Re: [gentoo-dev] Re: robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 07:16 AM, viv...@gmail.com wrote: On 05/22/13 13:06, Michael Palimaka wrote: On 22/05/2013 20:41, Thomas Sachau wrote: Michael Palimaka schrieb: On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. I am confused as to what you are proposing. Do you want arch teams to continually test packages that are already in stable to make sure they haven't broken somehow? The point is probably, that when you stable a package with inactive maintainer, there will be noone following the opened bugs against this new version. So this looks like a case, where one should ask for a new maintainer, who then decides about the stable versions instead of doing auto-stabilization. If the maintainer is inactive, presumably nobody is looking at bugs for the old version either. And the circle is closed since we started with the correlation no answer to stable bug in 30 days = package unmantained ;-) This could actually work -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGcwi8ACgkQ2ugaI38ACPDVLQEAkWpd//XIy8Newa+TCdHbltKr eeRByNJDLKTwowwoTzMA/iGM9q2vvnCeSYr0J3I60qiTgVBxAGIcOQTXmYbdsUW8 =4KjF -END PGP SIGNATURE-
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 09:03:43 -0400 Ian Stakenvicius a...@gentoo.org wrote: And the circle is closed since we started with the correlation no answer to stable bug in 30 days = package unmantained ;-) This could actually work Then we'd get the Ubuntu/Launchpad situation, where several bugs that I filed more than 4 years ago are still being actively flipped from on to off and back, invalid to confirmed to wontfix to cantfix and so on for various reasons, including that the actual maintainers of the bugs' targets didn't respond in time. It definitely put me off filing any new bug reports against Ubuntu packages. Possibly forever. jer
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 19:18:41 +1000 Michael Palimaka kensing...@gentoo.org wrote: Yet the base system lead went and apply it to any stabilization bug; as both him and Jer (the bug wrangling lead) do it this way, I'll be doing it as well. Let's not be inconsistent with our leads unless there is a wide decision to do so; I expect none will come, unless you really think this should become Council material. According to the bug-wrangler's own docs[1]: A stabilisation request should be handled by the package's maintainer, so you should not CC arch teams in your role as bug wrangler, nor set the STABLEREQ keyword in the Keywords field.. There should at least be some consistency there before telling people what to do. Just asked the bug wranglers lead to fix that up. As for base system, I don't really see what bearing their actions has to do with anything to on bugzilla. The keywords are theirs afaik, how their keywords are used is relevant. Let's not forget that the current lead has a history of doing whatever he wants, so I don't think the actions that come out of that are a good example to follow. Sub project members behaving differently is annoying, that's why I've asked before that the lead(s) attempt to bring some consistency in the way that bugs are dealt with and what is expected from bug wranglers. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 10:51 AM, Jeroen Roovers wrote: On Wed, 22 May 2013 09:03:43 -0400 Ian Stakenvicius a...@gentoo.org wrote: And the circle is closed since we started with the correlation no answer to stable bug in 30 days = package unmantained ;-) This could actually work Then we'd get the Ubuntu/Launchpad situation, where several bugs that I filed more than 4 years ago are still being actively flipped from on to off and back, invalid to confirmed to wontfix to cantfix and so on for various reasons, including that the actual maintainers of the bugs' targets didn't respond in time. It definitely put me off filing any new bug reports against Ubuntu packages. Possibly forever. jer (reading this, I have a fully feeling this was actually in response to the other email I wrote, relating to status changes; however in case it wasn't...) ... just trying to wrap my head around how this would play out: 1- stabilization bug filed 2- no response for 30 days 3- timeout script marks package for maintainer-needed (say, by adding a keyword and a comment) .. script should check devaway first on the maintainers, if devaway then stop at #2. 4- say, another 30 days timeout (longer? how about 90?) 5- a team (treecleaners? or other?) actually marks package maintainer-needed (removing keyword from the bug), assuming the maintainer(s) are not devaway. 6- announcement that package is up for grabs (maybe just in the 'weekly summary'?) The stabilization request bug would still be valid and open even if the package moves to maintainer-needed; probably that indication would occur via a KEYWORD rather than a reassignment of the summary. Any dev that chose to get involved and cause deviation at any point in the above list, would stop the process in its tracks, afaict. I don't see how things would flip back again to repeat the whole process Note, on #3, it would really aid this process if the particular maintainer(s) of a package within a herd was listed in the metadata -- iirc for say, x11 herd, certain packages are only touched by one member of the herd even though it just has a herd tag. I think this could make things smoother for many interactions and not just the above. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGc34QACgkQ2ugaI38ACPAYlQEAjVv44o1Ry3jpfAnFePYJEyBn FNZotaz/D71deOjsbT4A/2pvdMRE+BcmRhQmBj14zXlycwYARcPw8ayoP2kNi8Vh =27YH -END PGP SIGNATURE-
Re: [gentoo-dev] Re: robo-stable bugs
On Tue, 21 May 2013 00:46:22 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: As a user, I've understood: * Severity is something the user/filer can use. So when Chromium doesn't compile on your machine, you set it as a Blocker, and then it gets reverted to Normal because it works fine for the other 99,9%. Individual users are probably not best suited to discover the scope of a bug report, let alone the actual bug, if there is one. If the Severity does not get reverted to Normal, then we can safely assume it's being completely ignored. The interpretation of Severity is highly dependent on the type of bug report. It's already diverting strongly between stabilisation requests, security vulnerabilities and changes to documentation. The meaning of the field thusly changes according to the Product/Component and other fields. * Priority is strictly for maintainers/teams if they want to use it, NOT the user/filer (unless it's a maintainer filed bug). There is no policy here except where herds/teams specifically set them out. Even so, if there's no known-approved reason to set severity, a user should just leave it alone. That means users unfamiliar with gentoo's bugzilla should just leave it alone. Agreed. * If it's an enhancement I mark it as such, and expect maintainer bug priority ranked less urgent as a result. The *.desktop file example someone mentioned goes here, What if a bad/missing .desktop file stops you from running an app through your DM/another app trying to find an appropriate program to open a file in? * If the bug has system-wide or arch-class-wide (all ~arch, for instance) implications, I'll sometimes up severity accordingly, with a note in the text explaining my reasoning. Toolchain or base-system bugs that prevent normal boot or system upgrade arguably fit here, especially if they're on a recently (say a day) unmasked or announced to be unmasked package with arch-class-wide implications, where an immediate remask might be appropriate until the situation can be resolved. What if your initial analysis completely misses the mark? Then you end up with an INVALID Blocker with one or more devs investigating hours in a user error. How did setting Severity help here? In conclusion, setting Severity can only be properly done after an actual bug has been appreciated, not at the time you file the bug report. * Also, arugably many security bugs could get severity-upgraded, altho with security handled separately on gentoo, I'd discourage that unless again it's something like toolchain or base-system, thus fitting the above system-wide condition. As explained above, the security team has its own rules. jer
Re: [gentoo-dev] Re: robo-stable bugs
On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill dirtye...@gentoo.org wrote: Huh? The severity of the bug is it's an enhancement. The point I was making is we could improve things by a fair margin. If all stabilisation bugs had a Severity that actually reflected the severity, then I'd pay attention to it. Right now only the security team gets it right, it seems. Yes stabilizations are enhancements. Always have been. Looking through more than eight and a half years of stabilisation bug mail, I can definitively confirm that you are wrong. It wasn't always this way and it changed very recently. Again, the status quo is no reason to not improve the status quo. Also, your script does not set the STABLEREQ keyword. People are having to hunt down your robo-stabilisation requests and add it themselves. You should just do it yourself or turn your script off. Did you read the message? The point is you're supposed to add that yourself. It's not a STABLEREQ until you add arches. Yes, I've read its nearly useless contents way too many times. It is awful. It could probably be improved and refreshed in even more ways than I and others have suggested so far. It could include actual information, for starters, instead of things that should probably be in some policy document or guide. Adding STABLEREQ can't be done through the bugzilla API until after the bug is filed, which was the technical reason it isn't done, I've been told. That's a technical problem we can solve. jer
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 19:18:41 +1000 Michael Palimaka kensing...@gentoo.org wrote: A newer version of a package is usually considered to be better in some way, hence it is an enhancement. Unless it's a Blocker, of course. :) According to the bug-wrangler's own docs[1]: A stabilisation request should be handled by the package's maintainer, so you should not CC arch teams in your role as bug wrangler, nor set the STABLEREQ keyword in the Keywords field.. There should at least be some consistency there before telling people what to do. I am trying to find consensus based on reasonable argument here. [1]: http://www.gentoo.org/proj/en/qa/bug-wranglers/ Documentation/policy should change after discussion. I set up the b-w project to get something of a standard going, not to [tell] people what to do. I have been adding STABLEREQ recently because it's turning out to be more practical (mainly because developers keep forgetting to add it, despite the helpful suggestion from the robo-script). I will change the default in the b-w doc if I find there is reasonable consensus on the matter. jer
[gentoo-dev] Re: robo-stable bugs
On Tue, 21 May 2013 16:17:30 -0400 Alexis Ballier aball...@gentoo.org wrote: On Tue, 21 May 2013 20:51:52 +0100 Markos Chandras hwoar...@gentoo.org wrote: I'd rather not see this process changes, because it has helped bringing the stable tree up2date. However, given that *a few* people don't like it, I suggest you don't file bugs for packages owned by them. +1 I am (was) unhappy with some corner cases that used to happen (like bug #428968 ) but overall I consider it very useful; I'm even becoming more lazy and do not look for stable candidates because I know some day I'll have an automated request :P Yes my laziness won out against any objections too. :) -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
On Sun, 19 May 2013 15:40:27 +0200 Jeroen Roovers j...@gentoo.org wrote: OS: Linux Status: CONFIRMED Severity: enhancement Is a stabilisation an enhancement per se? If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) Huh? The severity of the bug is it's an enhancement. Yes stabilizations are enhancements. Always have been. Also, your script does not set the STABLEREQ keyword. People are having to hunt down your robo-stabilisation requests and add it themselves. You should just do it yourself or turn your script off. Did you read the message? The point is you're supposed to add that yourself. It's not a STABLEREQ until you add arches. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
Rich Freeman posted on Mon, 20 May 2013 13:15:09 -0400 as excerpted: Severity and Priority on the Gentoo Bugzilla have always been weird to me; I would love to hear from someone who is actually using either of those to sort their bugs and using them happily, because the inconsistency applied by different people is making a mess of them. I suspect we could just get by with one field. Typically at work the severity reflects impact of a bug (the effects it has on customers), and the priority reflects management direction on what developers should be working on. Our fields are a bit of a mish-mash of both, and of course maintainers can generally ignore or work on bugs in any order with little impact on their salary. It does make sense to distinguish between a bug holding up the next gcc release (scheduled a week in the future) and adding a desktop entry to a package that otherwise works just fine. As a user, I've understood: * Severity is something the user/filer can use. * Priority is strictly for maintainers/teams if they want to use it, NOT the user/filer (unless it's a maintainer filed bug). Thus there's reason to have two separate fields, one that's specifically reserved for the maintainer, one for the user, that a maintainer can choose to ignore if they decide to. Even so, if there's no known-approved reason to set severity, a user should just leave it alone. That means users unfamiliar with gentoo's bugzilla should just leave it alone. Here, I only use severity in a few cases, generally the exception rather than the rule. * If it's an enhancement I mark it as such, and expect maintainer bug priority ranked less urgent as a result. The *.desktop file example someone mentioned goes here, as do, arguably, changes such as the md initscript improvements I filed some years ago (tho those could equally arguably be left as normal by the user and let the maintainer decide, I'd certainly not argue a maintainer changing that to/from enhancement). * If the bug has system-wide or arch-class-wide (all ~arch, for instance) implications, I'll sometimes up severity accordingly, with a note in the text explaining my reasoning. Toolchain or base-system bugs that prevent normal boot or system upgrade arguably fit here, especially if they're on a recently (say a day) unmasked or announced to be unmasked package with arch-class-wide implications, where an immediate remask might be appropriate until the situation can be resolved. * Also, arugably many security bugs could get severity-upgraded, altho with security handled separately on gentoo, I'd discourage that unless again it's something like toolchain or base-system, thus fitting the above system-wide condition. Based on the above, I'd suggest that: * The priority field should be restricted to devs (if it's not already), and that devs who misuse the field on packages they don't maintain be treated accordingly. * The severity field is arguably a candidate for first gentoo privilege, restricted for ordinary users, but with a moderately liberal on-request policy, for users who have demonstrated consistent responsible bug filing, on gentoo bugzy at least, but also those who can point to bugs filed elsewhere in the community, package upstream and peer- distro maintainers, etc. Of course the first gentoo privilege is requisite on the appropriate infrastructure being in place to handle it, and would arguably be settable by anyone with higher gentoo bugzilla privs. If implemented, constructing an initial whitelist might be in order. A note in gentoo bugzy suggesting that users can request severity privilege in any filed bug, should they believe they can handle it responsibly, could be appropriate as well. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: robo-stable bugs
On 19/05/2013 23:40, Jeroen Roovers wrote: OS: Linux Status: CONFIRMED Severity: enhancement Is a stabilisation an enhancement per se? Usually I think so yes. If it is an urgent stabilisation there is priority field. If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) According to the Bugzilla docs: Severity - How severe the bug is, or whether it's an enhancement. so there is no such thing as an enhanced severity. Priority: Normal This is where you probably wanted to set something similar to Enhancement above, but again you probably shouldn't. Normal stabilisation bugs are normal, not less than normal. Why should enhancement go in the priority field, when it does not presently exist there but does exist in the severity field? Also, your script does not set the STABLEREQ keyword. People are having to hunt down your robo-stabilisation requests and add it themselves. You should just do it yourself or turn your script off. According to the bug wrangler docs STABLEREQ should be handled by the maintainer. Why should there be a difference whether a user or a dev is requesting stabilisation?
