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
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
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
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.
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
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
