Re: [gentoo-dev] robo-stable bugs
On 5/20/13 9:58 AM, Paweł Hajdan, Jr. wrote: On 5/20/13 5:10 AM, Gilles Dartiguelongue wrote: This generally needs to go first so sorting by summary shows your packages in order and you have a chance to see this part of the summary in bugzilla (with version optionally), the rest of the summary line is imho less important when working through the web interface. This makes sense. I'll post an update when I make this simple change to the script. As promised I'm announcing I made this change: http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=a92c88330af1aec3aa9ee58dc497f047129ccd2e The original thread got somewhat long, so if I've missed any other feedback on which there is a consensus, please let me know. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
Am Samstag, 27. Juli 2013, 21:29:15 schrieb Paweł Hajdan, Jr.: The original thread got somewhat long, so if I've missed any other feedback on which there is a consensus, please let me know. Hi Pawel, a general idea that might be helpful: * document your policies on a web page or wiki page * add a link to that page to the stablereq bug text This way we can avoid or at least shorten future discussions about the robostabling. Best, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2013 08:29 PM, Tom Wijsman wrote: We have `iamlate` for this in app-portage/gentoolkit-dev. /usr/bin/imlate , nice ;-) - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlGlyLAACgkQknrdDGLu8JDJ3QEAhYrgzLHT5NCINaXBVYCNs1PH 12+nHNMy9V+6BQ4EMi8A/RLvadt7RndQPk8m5BuDlzRuwaO05WNVfkArMOxovd1v =7eoE -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs, the flipside
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/05/13 04:14 PM, Markos Chandras wrote: On 23 May 2013 19:49, Ian Stakenvicius a...@gentoo.org wrote: On 23/05/13 02:40 PM, Markos Chandras wrote: On 23 May 2013 19:11, Ian Stakenvicius a...@gentoo.org wrote: Here's a new question on the robo-stable front -- I want to file a bug (by hand, probably) on the next stable candidate for my package and have the robo-stable script CC arches and STABLEREQ after 30 days (assuming no other bugs pop up) Is that doable? (for those of us too lazy to put an entry in our calendars :) I guess you could use pybugz + cron to do what you want. Are the sources for the auto-stable etc. script posted somewhere? I don't think i've actually seen a URL at all in this thread (or the one from a couple of months ago).. I believe the sources are hosted here http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary Perfect, thanks!! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGfZQgACgkQ2ugaI38ACPD9/AEAgZe/nARVLScK/7iapVuXmLEb vvqDuP2C4Qld5nMfEp4A/iJT+vvpQb26XGZ3tTvXnc1oM4Y7RJPeniWyQGOcVNeZ =2hK+ -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs, the flipside
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/05/13 03:29 PM, Rich Freeman wrote: On Thu, May 23, 2013 at 2:49 PM, Ian Stakenvicius a...@gentoo.org wrote: Are the sources for the auto-stable etc. script posted somewhere? I don't think i've actually seen a URL at all in this thread (or the one from a couple of months ago).. By all means publish your script when done. That seems like it would be useful for many, and certainly there would be no objections when used by package maintainers. It is just automating a repetitive task. Rich Certainly! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGfZVYACgkQ2ugaI38ACPDNRQD+O7f2xequ8KK/MmQXjSJHaQmP FB4IVo6tLzuPEhTFqJ4A+gN2gVRNqpL/g9674Uzsjl+znK4z/SNpavTsjKNFdu/q =E6r8 -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 07:03 PM, Rick Zero_Chaos Farina wrote: On 05/22/2013 09:11 AM, Ian Stakenvicius wrote: On 21/05/13 11:46 PM, Rick Zero_Chaos Farina wrote: I do, however, completely agree that there should be some way to leave the bug open and state that it will be stabled later. Would a comment trigger this in the script? That seems semi-sane. If the maintainer wanted to stabilize things they would cc arches, any other comment could likely be understood to mean don't auto-stable this. Maybe we can do something with bug status? Something along the lines maybe of filing as 'unconfirmed' and a dev setting it to 'confirmed' (or anything else) would make it be ignored by the auto-stabilizer ? Or maybe 'confirmed' is the initial status and a dev can set it to 'unconfirmed' or w/e... ? Changing Confirmed-Unconfirmed seems like a good policy. Also if we are going to start establishing such policies they should be posted somewhere and linked to from the autostabilization script's comment. I expect the script can probably work on the basis that any status other than what the bug was filed with is an exclusion for the auto-stable pass (confirmed-unconfirmed in this case). However, yes I agree it would be very useful to have a link to some page, describing the the whole autostabilization process (what the script does, how devs can interact with it). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGeEiUACgkQ2ugaI38ACPAeNAD/QcSQL7yufe2YpKTb2cV2VP0r WJoHs4uozZIsRDrYXjcA/1icODLSi/sjCl6+zRLjdiUKvRJbKiz2FZRzAtZ3IjFN =B9Pd -END PGP SIGNATURE-
[gentoo-dev] robo-stable bugs, the flipside
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here's a new question on the robo-stable front -- I want to file a bug (by hand, probably) on the next stable candidate for my package and have the robo-stable script CC arches and STABLEREQ after 30 days (assuming no other bugs pop up) Is that doable? (for those of us too lazy to put an entry in our calendars :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGeW8wACgkQ2ugaI38ACPA9HgEAqofd3JKguCgiaDCS65kD23U1 rqc6POpLzA9oW/qmYqoA/0fmOLcgxxQnIQ79wzBWfF+RjNhcx3rt/wJBvFdiDkSm =Ftge -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs, the flipside
On 23 May 2013 19:11, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here's a new question on the robo-stable front -- I want to file a bug (by hand, probably) on the next stable candidate for my package and have the robo-stable script CC arches and STABLEREQ after 30 days (assuming no other bugs pop up) Is that doable? (for those of us too lazy to put an entry in our calendars :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGeW8wACgkQ2ugaI38ACPA9HgEAqofd3JKguCgiaDCS65kD23U1 rqc6POpLzA9oW/qmYqoA/0fmOLcgxxQnIQ79wzBWfF+RjNhcx3rt/wJBvFdiDkSm =Ftge -END PGP SIGNATURE- I guess you could use pybugz + cron to do what you want. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] robo-stable bugs, the flipside
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/05/13 02:40 PM, Markos Chandras wrote: On 23 May 2013 19:11, Ian Stakenvicius a...@gentoo.org wrote: Here's a new question on the robo-stable front -- I want to file a bug (by hand, probably) on the next stable candidate for my package and have the robo-stable script CC arches and STABLEREQ after 30 days (assuming no other bugs pop up) Is that doable? (for those of us too lazy to put an entry in our calendars :) I guess you could use pybugz + cron to do what you want. homebrew, but it'd work. Are the sources for the auto-stable etc. script posted somewhere? I don't think i've actually seen a URL at all in this thread (or the one from a couple of months ago).. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGeZMgACgkQ2ugaI38ACPDeyQEAkgSoq/dJtCQjUBTJHSwTIk13 0odYcxYgcias45vE2vkA/j0UZRNFZbPtRhmyg9L5CO6LvfbAz92OY88wy0dcYYB5 =Nh5F -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs, the flipside
On Thu, May 23, 2013 at 2:49 PM, Ian Stakenvicius a...@gentoo.org wrote: Are the sources for the auto-stable etc. script posted somewhere? I don't think i've actually seen a URL at all in this thread (or the one from a couple of months ago).. By all means publish your script when done. That seems like it would be useful for many, and certainly there would be no objections when used by package maintainers. It is just automating a repetitive task. Rich
Re: [gentoo-dev] robo-stable bugs, the flipside
On 23 May 2013 19:49, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/05/13 02:40 PM, Markos Chandras wrote: On 23 May 2013 19:11, Ian Stakenvicius a...@gentoo.org wrote: Here's a new question on the robo-stable front -- I want to file a bug (by hand, probably) on the next stable candidate for my package and have the robo-stable script CC arches and STABLEREQ after 30 days (assuming no other bugs pop up) Is that doable? (for those of us too lazy to put an entry in our calendars :) I guess you could use pybugz + cron to do what you want. homebrew, but it'd work. Are the sources for the auto-stable etc. script posted somewhere? I don't think i've actually seen a URL at all in this thread (or the one from a couple of months ago).. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGeZMgACgkQ2ugaI38ACPDeyQEAkgSoq/dJtCQjUBTJHSwTIk13 0odYcxYgcias45vE2vkA/j0UZRNFZbPtRhmyg9L5CO6LvfbAz92OY88wy0dcYYB5 =Nh5F -END PGP SIGNATURE- I believe the sources are hosted here http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] robo-stable bugs
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.
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/05/13 07:43 PM, Thomas Sachau wrote: [ Snip reasons for why opt-out is bad ] So why don't we add something to package metadata, to indicate that a package is OK to be considered for auto-stabilization?? It lets everyone opt-in, and we still have the opportunity to opt-out if we want to at stable-bug-request time (or better, the dev can file their own bug to indicate stabilization will not occur or will occur later once XYZ are met or w/e).. We include it in the default metadata.xml template going forward, and request all dev's add it to their packages if they want to contribute. Thoughts? (Note: I also recall there being some sort of blacklist mentioned, where is the info for that stored? IE, how could I put a package in that blacklist?) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGcv7IACgkQ2ugaI38ACPA9ewEAp5IwDre3O8iz+UurnAhDsCF5 fIWcearEExwknl14U48A/0IW0sI0Yxs+qnQnJaE1kUut/kQT6PxanFGqz3mV+oiI =zqJh -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
On 05/22/2013 08:53 AM, Ian Stakenvicius wrote: On 21/05/13 07:43 PM, Thomas Sachau wrote: [ Snip reasons for why opt-out is bad ] So why don't we add something to package metadata, to indicate that a package is OK to be considered for auto-stabilization?? It lets everyone opt-in, and we still have the opportunity to opt-out if we want to at stable-bug-request time (or better, the dev can file their own bug to indicate stabilization will not occur or will occur later once XYZ are met or w/e).. We include it in the default metadata.xml template going forward, and request all dev's add it to their packages if they want to contribute. Thoughts? (Note: I also recall there being some sort of blacklist mentioned, where is the info for that stored? IE, how could I put a package in that blacklist?) I was thinking something similar yesterday, except I'd rather it be seen as opt-out rather than opt-in. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/05/13 11:46 PM, Rick Zero_Chaos Farina wrote: I do, however, completely agree that there should be some way to leave the bug open and state that it will be stabled later. Would a comment trigger this in the script? That seems semi-sane. If the maintainer wanted to stabilize things they would cc arches, any other comment could likely be understood to mean don't auto-stable this. It does make a lot of sense that there be a way to flag whether the bug has been touched or not, and *only* auto-process it if it hasn't been touched. Of course there are some cases where changes would be OK (CC's added, for instance; also end-user comments but possibly dev comments)... Maybe we can do something with bug status? Something along the lines maybe of filing as 'unconfirmed' and a dev setting it to 'confirmed' (or anything else) would make it be ignored by the auto-stabilizer ? Or maybe 'confirmed' is the initial status and a dev can set it to 'unconfirmed' or w/e... ? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGcxAoACgkQ2ugaI38ACPA4/AEAp7ezuWH8GjdkrM/1wsidA5Gw iK0+RvCt3xXQBWK+9yYBAI7R/77W154YZ40W28dRDvMHavR1RazzmSffE9FRiTCT =Bclk -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
On Wed, May 22, 2013 at 5:22 AM, viv...@gmail.com 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. While I can see the logic here, I'd suggest that if we're going to refuse to stabilize because we don't think there is a maintainer, then we should mark the package as maintainer-needed while we're at it. Packages listed with maintainers who don't actually stabilize the package have several problems: 1. It diminishes the experience for stable users, which really should be the best experience we offer (and yes, I know that this is often not the case, hence the need to improve things). 2. The fact that a maintainer is already listed means that nobody else steps up to maintain it either. If a package is maintained, it should be stabilized (unless this is inappropriate due to the nature of the package itself, and that just requires asking for whitelisting). If a package isn't maintained, then it should be marked as such. Rich
Re: [gentoo-dev] robo-stable bugs
On Tue, 21 May 2013 15:32:25 +0200 Thomas Sachau to...@gentoo.org wrote: Automagic stabilization is a bad idea. I agree. Maintainer timeout is not a valid reason to go ahead with stabilisation. If you really want to push forward, you should be required to do more research as bug reporter. And just because a maintainer can opt-out per bug, it does not change the automagic behaviour nor does it make this thing any better. In this case, there are enough possible cases, where a maintainer does miss the bug, so again a package may become stable, also it should never have been a stable candidate. So again: If a specific ebuild should never go stable but is, by default, a stable target, then you can do several things: 1) Remove it from the tree If it should never go stable, then ask yourself why it's in the tree. 2) Put it in package.mask Add some reasons, like bug reports that explain what needs to be done to once again make it a stabilisation target. 3) File a bug report detailing while it shouldn't go stable Ebuilds with open bugs should never go stable. This is detailed in the (correct answers to the) quizzes and so on, IIRC, and in [1]. This makes robo-stable requests difficult, though, since the bug report in question could be summarised as some-cat/pkg with stable/target has issue foo and then phajdan.jr's robo-script should be able to recognise it.[2] jer [1] http://devmanual.gentoo.org/keywording/index.html [2] Or wait, some human interaction is again called for to fix the bureaucratic mess the script created! Since we still cannot pinpoint a specific cat/pkg/ver-rev in a bug report, it's down to scraping and regexen again.
Re: [gentoo-dev] robo-stable bugs
On Wed, 22 May 2013 08:53:06 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/05/13 07:43 PM, Thomas Sachau wrote: [ Snip reasons for why opt-out is bad ] So why don't we add something to package metadata, to indicate that a package is OK to be considered for auto-stabilization? Package or ebuild or SLOT or what? Please explain what these metadata.xml entries should look like. Also, since we're working per ebuild, and not per package, why couldn't we include this in each individual ebuild? What happens when you've set the variable, tag or whatever, and then an obscure bug pops up (and you're not CC'd because the bug appears in a dependent package three branches removed) and then your robo-call comes in for that ebuild? It's a neat idea, but the red tape would stretch to Alpha Centauri and back. IOW, it's hardly maintainable unless you can afford the espresso machine and all of your spare time. Common sense and proper research usually cuts that short. Automating CC'ing arch teams would probably only catch this in a very late stage, if at all in time before an ebuild is deemed stable. jer
Re: [gentoo-dev] robo-stable bugs
On Mon, 20 May 2013 17:29:43 +0200 Tom Wijsman tom...@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. Maintainer(s) and arch team member(s) blamed me for setting this. :( I have frankly never heard that one before. Setting STABLEREQ *and* CC'ing is probably what went wrong there? jer
Re: [gentoo-dev] robo-stable bugs
On 05/22/2013 11:00 AM, Jeroen Roovers wrote: On Wed, 22 May 2013 08:53:06 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/05/13 07:43 PM, Thomas Sachau wrote: [ Snip reasons for why opt-out is bad ] So why don't we add something to package metadata, to indicate that a package is OK to be considered for auto-stabilization? Package or ebuild or SLOT or what? Please explain what these metadata.xml entries should look like. Also, since we're working per ebuild, and not per package, why couldn't we include this in each individual ebuild? What happens when you've set the variable, tag or whatever, and then an obscure bug pops up (and you're not CC'd because the bug appears in a dependent package three branches removed) and then your robo-call comes in for that ebuild? It's a neat idea, but the red tape would stretch to Alpha Centauri and back. IOW, it's hardly maintainable unless you can afford the espresso machine and all of your spare time. Common sense and proper research usually cuts that short. Automating CC'ing arch teams would probably only catch this in a very late stage, if at all in time before an ebuild is deemed stable. jer My expectation is that something in metadata.xml would operate *per-package* to allow the maintainer of that package to say hey, let me do my own thing here. Trying to set those values per-ebuild sounds like a bug farm as those values are accidentally set wrong from time to time. Then you try writing something to automate the maintainer side of things, and you've got more lines of (theoretically possibly buggy) code to worry about. let me do my own thing here would start off as don't touch my packages. Trying to plan more granularity than that at the outset seems a lot like trying to tell the future. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 11:14 AM, Michael Mol wrote: On 05/22/2013 11:00 AM, Jeroen Roovers wrote: On Wed, 22 May 2013 08:53:06 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/05/13 07:43 PM, Thomas Sachau wrote: [ Snip reasons for why opt-out is bad ] So why don't we add something to package metadata, to indicate that a package is OK to be considered for auto-stabilization? Package or ebuild or SLOT or what? Please explain what these metadata.xml entries should look like. Also, since we're working per ebuild, and not per package, why couldn't we include this in each individual ebuild? What happens when you've set the variable, tag or whatever, and then an obscure bug pops up (and you're not CC'd because the bug appears in a dependent package three branches removed) and then your robo-call comes in for that ebuild? It's a neat idea, but the red tape would stretch to Alpha Centauri and back. IOW, it's hardly maintainable unless you can afford the espresso machine and all of your spare time. Common sense and proper research usually cuts that short. Automating CC'ing arch teams would probably only catch this in a very late stage, if at all in time before an ebuild is deemed stable. jer My expectation is that something in metadata.xml would operate *per-package* to allow the maintainer of that package to say hey, let me do my own thing here. Trying to set those values per-ebuild sounds like a bug farm as those values are accidentally set wrong from time to time. Then you try writing something to automate the maintainer side of things, and you've got more lines of (theoretically possibly buggy) code to worry about. let me do my own thing here would start off as don't touch my packages. Trying to plan more granularity than that at the outset seems a lot like trying to tell the future. I agree - the metadata addition I would propose would be for metadata.xml, and would be per-package. It would also be specifically for the auto-stablereq script(s) (or for people, if this changes in the future to something a team works on) to read. Handling individual package versions -could- be done via metadata.xml, but that would ..well, jer described what that'd be like. :) Plus metadata.xml probably shouldn't change with every version bump. I think it'd be best to just handle individual package versions by opening a bug (as then the stabilizer script would just skip that $PV anyhow). All in all, this isn't much different from the idea i mentioned a while ago, about dev's putting in an others feel free to touch my stuffs / touch these ebuilds and i kill your first born entry in metadata.xml -- it's just stabilization specific. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGc4q0ACgkQ2ugaI38ACPApeQEAjs5IZ6KVXWLJQJ+NNbekvyub nidlgWEVs2YXJiOLHWMA/0iArPM7T4a2hJruNw5MVmbEfYvwu66HrOFhue9LSPRA =5T7z -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
On Wed, 22 May 2013 17:03:21 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 20 May 2013 17:29:43 +0200 Tom Wijsman tom...@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. Maintainer(s) and arch team member(s) blamed me for setting this. :( I have frankly never heard that one before. Setting STABLEREQ *and* CC'ing is probably what went wrong there? Nope, effectively just adding the STABLEREQ keyword and not CC-ing anyone had someone ping me on IRC. Similarly I've had people ping me about KEYWORDREQ as well (but that was according to policy and agreed). -- 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] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/22/2013 09:11 AM, Ian Stakenvicius wrote: On 21/05/13 11:46 PM, Rick Zero_Chaos Farina wrote: I do, however, completely agree that there should be some way to leave the bug open and state that it will be stabled later. Would a comment trigger this in the script? That seems semi-sane. If the maintainer wanted to stabilize things they would cc arches, any other comment could likely be understood to mean don't auto-stable this. It does make a lot of sense that there be a way to flag whether the bug has been touched or not, and *only* auto-process it if it hasn't been touched. Of course there are some cases where changes would be OK (CC's added, for instance; also end-user comments but possibly dev comments)... Maybe we can do something with bug status? Something along the lines maybe of filing as 'unconfirmed' and a dev setting it to 'confirmed' (or anything else) would make it be ignored by the auto-stabilizer ? Or maybe 'confirmed' is the initial status and a dev can set it to 'unconfirmed' or w/e... ? Changing Confirmed-Unconfirmed seems like a good policy. Also if we are going to start establishing such policies they should be posted somewhere and linked to from the autostabilization script's comment. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRnU6yAAoJEKXdFCfdEflKe4oQAK9ObsiJ2ZXUVM5K8n4Vnl+W 8vLzqTjPtWJbhFSIdAVA2RzzxXWSAl7Gza+TlMX764DCJQQcEXRnulQXAEyqKAaL OPlhc9SlhnXa2WA3D0f/koY8NSOPu2vxqe+TXlgwgrysWruBPugTqtTrdjd1fmfy fLlX3ANekbKa06Rc16Q8am9OxVvU/GlRJ7FbUh1c16wxsX0edjBEbg2Ze0kDyeMU ajK4sC+ocZSNM79TjMgWhAzOKCH1XCgHW61dh0h8nJ/SEGJLW5V+yKbH3/oIlSAN nLiBVEtprBeySbMRKDafMvgjW2Zk90blckPBYhtAJQ70oYtZsIXdqRb3WEdyuQGX I55JAaHsRnOdppwiOGZRKnHi34ExTACx5XjKOZs0c9C5z1yELfFhFT9iyVoIB7z/ 3X1KM55UvLK1R9RCwdwSo5JxlI3ezUUdnVIZnGMS9mzf/mHijZVGpt11pTHXyxQi fsppqDAAzhomuaudYnRfFRqyJy+ZikeQGTlG2dWIBPdXaS3gxF+0j2ipUqyZASMx 7krVlL0IDDQQfdyug2zl8b9R/gInkei4oovnz89DepcbmVsIDF2Ndd2sB1LTvHvv 9VYDvVrcd7JZL+hsXIpCfZpXOfsmhPrOaPn3nau2ZSq6j9WCPj9o7kGFT6L3+luX vOM9X+tAxHdjNW7CJrNm =aze5 -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
Paweł Hajdan, Jr. schrieb: Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. Paweł Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
Thomas Sachau schrieb: Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. This is why the maintainer can object within 30 days (or so) or block the stabilization bug with another one which details the reasons why the package should not be stabilized. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] robo-stable bugs
On 21 May 2013 13:21, Thomas Sachau to...@gentoo.org wrote: Paweł Hajdan, Jr. schrieb: Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. Paweł Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. -- Thomas Sachau Gentoo Linux Developer If you don't read your bugmail in 30 days then that is a different problem. I like the way Paweł handles this at the moment. 30 days is enough time for active maintainers to object. We just can't afford waiting months for inactive maintainers to act. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] robo-stable bugs
Chí-Thanh Christopher Nguyễn schrieb: Thomas Sachau schrieb: Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. This is why the maintainer can object within 30 days (or so) or block the stabilization bug with another one which details the reasons why the package should not be stabilized. Best regards, Chí-Thanh Christopher Nguyễn I guess, you missed my point, so let me repeat it: Automagic stabilization is a bad idea. And just because a maintainer can opt-out per bug, it does not change the automagic behaviour nor does it make this thing any better. In this case, there are enough possible cases, where a maintainer does miss the bug, so again a package may become stable, also it should never have been a stable candidate. So again: Automatic scripts with maintainer opt-in are ok, anything else is a bad idea. Beside this, i have never seen any announcement about such scripting behaviour, which makes this automagic even worse, since it is unexpected for maintainers, who might e.g. keep a stable request bug open for later or to avoid dups. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
Markos Chandras schrieb: On 21 May 2013 13:21, Thomas Sachau to...@gentoo.org wrote: Paweł Hajdan, Jr. schrieb: Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. Paweł Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. -- Thomas Sachau Gentoo Linux Developer If you don't read your bugmail in 30 days then that is a different problem. I like the way Paweł handles this at the moment. 30 days is enough time for active maintainers to object. We just can't afford waiting months for inactive maintainers to act. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang So you are a perfect human with a perfect computer and a perfect environment? :-) For everyone else, there are already enough possible issues with the starting point of the bug mails (mail accidently deleted by user or some spam setup, read mail, planned for later, forget or just planned to keep the stable request bug open for some later stabilization time etc). So again: I accept opt-in solutions, but opt-out is a no go for stable request bugs. 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. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On 5/21/13 6:38 AM, Thomas Sachau wrote: 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. Thomas, this effort is going on for over a year now (and has been discussed on gentoo-dev). If it's only now you've noticed, maybe the sky isn't falling after all. Note the criteria for the bugs to be filed: 1. No open bugs for the package. 2. No bugs (including closed) for that particular version of the package (so for example closing the stabilization bug will prevent it from being opened again; it also takes into account bugs closed with e.g. NEEDINFO, which can be real issues). 3. At least 30 days in tree. 4. No repoman errors when trying to stabilize it (so all deps already stable). Also, arch teams are responsible for at least shallow (compile) testing of the package, and ideally smoke testing on run and possibly testing with various USE flag combinations and reverse dependencies testing (the latter is a regular part of my stabilization workflow, and the script for that is part of the same suite that files bugs). Note that there is a tradeoff here: I really started the stabilizations after I've noticed how many bugs are fixed in ~arch that still affect stable, but the fixing version didn't get stabilized. This is the downside of an opt-in approach, since inactive maintainers are not going to opt-in. Finally, everyone from metadata.xml is CC-ed. There is no trying a different maintainer - all of them are there since day one. Please let me know if you still have concerns - ideally back them with data and actual cases showing problems (or scenarios that can reasonably be likely) instead of just saying it _might_ lead to breakages. Anything _might_ lead to breakages, including taking no action here and allowing bugs to be not fixed for stable. :) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On 21 May 2013 19:32, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/21/13 6:38 AM, Thomas Sachau wrote: 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. Thomas, this effort is going on for over a year now (and has been discussed on gentoo-dev). If it's only now you've noticed, maybe the sky isn't falling after all. Note the criteria for the bugs to be filed: 1. No open bugs for the package. 2. No bugs (including closed) for that particular version of the package (so for example closing the stabilization bug will prevent it from being opened again; it also takes into account bugs closed with e.g. NEEDINFO, which can be real issues). 3. At least 30 days in tree. 4. No repoman errors when trying to stabilize it (so all deps already stable). Also, arch teams are responsible for at least shallow (compile) testing of the package, and ideally smoke testing on run and possibly testing with various USE flag combinations and reverse dependencies testing (the latter is a regular part of my stabilization workflow, and the script for that is part of the same suite that files bugs). Note that there is a tradeoff here: I really started the stabilizations after I've noticed how many bugs are fixed in ~arch that still affect stable, but the fixing version didn't get stabilized. This is the downside of an opt-in approach, since inactive maintainers are not going to opt-in. Finally, everyone from metadata.xml is CC-ed. There is no trying a different maintainer - all of them are there since day one. Please let me know if you still have concerns - ideally back them with data and actual cases showing problems (or scenarios that can reasonably be likely) instead of just saying it _might_ lead to breakages. Anything _might_ lead to breakages, including taking no action here and allowing bugs to be not fixed for stable. :) Paweł 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. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] robo-stable bugs
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 Alexis.
Re: [gentoo-dev] robo-stable bugs
On 5/21/13 1:17 PM, Alexis Ballier 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; Thanks, Alexis. One note about that bug: with lots of bugs being filed, it's not really feasible for me to track comments like that one. If there was a bug on file about dev-ml/camlp5 breaking coq, my script wouldn't consider dev-ml/camlp5 for stabilization - I think this is the right thing for you to do in such cases, much better than implicit bugs that are not in the bug tracker. :) 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 Note that there are several things my script will ignore: 1. Packages with any bugs open. 2. Packages which have at least one ~arch dependency. I still recommend doing some pass over packages you maintain to look for any stable candidates. Hopefully thanks to the script you should need to do that less often. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/21/2013 09:20 AM, Markos Chandras wrote: On 21 May 2013 13:21, Thomas Sachau to...@gentoo.org wrote: Paweł Hajdan, Jr. schrieb: Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. Paweł Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. -- Thomas Sachau Gentoo Linux Developer If you don't read your bugmail in 30 days then that is a different problem. I like the way Paweł handles this at the moment. 30 days is enough time for active maintainers to object. We just can't afford waiting months for inactive maintainers to act. I have to agree very strongly with this sentiment. If I'm ignoring my bugmail for 30 days and there are no (new) active bugs against the package it should be stabilized. The only time this shouldn't happen is if there is a bug in the new version which isn't present in the old version. We all need to learn to either be more responsive or stop complaining when other people fix our stuff. If you don't respond to your bugmail in 30 days then active maintainer is a bit of a stretch unless you have devaway setup. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRm+WEAAoJEKXdFCfdEflKNr4QAJoknm4/y8kCAjvYRbz8MfVF Ncgis7d6gzDW0yjypHvj8WO40xzok6WSYR6PsdZ+ZZYbviGjPmuTAvnu4eq0XNKN /CVc2cxsPrvgH+vD7dU8zaIkYI/0lrMhB3ZF6jmAyNx5NI0VFcsd+ktL/o7oh3Mz 4Um5Di25GXhoHFxmxRS03geS/k01CHHpJhP13zH8cEyzEAwqIlqPMIu+SAGPtSnm LE7R0/sXYECM3TDaw1hF2TU3maBUv9ZJoSNRmwUYznL1Tm8M2Ns7q+L+OBGwBicB 1RZN+FabyEZenW34bhZfA1l49g8cA4l9QZPL+Zi5QudLoCuyjXCGPuyr0bL04hIy WTI4K4gZed1eKhtjOtt12tcc6LLsnCMmueTcGVDu0n1u8dV6BgX4YGjpdmyvREAP 3R7uaFAxx7c7t+uKzDodC4lCFKeE6rn6MPWQ0lVpNM05cxusi0X84iU6W0OmCKNE ef3GtsWbW2RevwoOE8MuY3fC87RtCi6z8sb35+IuXxsNzIBdrSFdRAf5Xh9AoEQ/ pbJTQxqxCx0oiX0JAJfE51bYSWN2Q9HY/U7Es/lcT8DimKXX569jgcrSx4OoFJgR erpB7tTn9WWr2B3wYL1FXLDOlcvJy6VzSEhssHO/51TeUQ20ZKl33GTuOuFRmVr4 jUMivXf1nrKnwB7ZQA6b =qesr -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
Pawel, Note that there are several things my script will ignore: 1. Packages with any bugs open. 2. Packages which have at least one ~arch dependency. how about putting up a webpage documenting your script policies? Just to shorten discussions like this one... The page need not be elaborate, but you could link to it in the bugreports. Something like This bug has been filed automatically, see http://... (and to everyone else, please don't complain about the extra text line in your bugmails now!) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
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. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
On Tue, 21 May 2013 13:46:18 -0700 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/21/13 1:17 PM, Alexis Ballier 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; Thanks, Alexis. One note about that bug: with lots of bugs being filed, it's not really feasible for me to track comments like that one. I know its not really feasible; in this case the annoying part is, besides the noise, the automated ccing of arches if there is no answer when there actually was one on the first request. Anyway, you seem to have fixed it because its been a while since I have not seen it (maybe by ignoring packages that have a wontfix automated stablereq bug?). Alexis.
Re: [gentoo-dev] robo-stable bugs
Paweł Hajdan, Jr. schrieb: On 5/21/13 6:38 AM, Thomas Sachau wrote: 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. Thomas, this effort is going on for over a year now (and has been discussed on gentoo-dev). If it's only now you've noticed, maybe the sky isn't falling after all. I dont remember any auto-stabilization being accepted, but maybe this happened in number 30 or 50 of some thread, where i already got bored and did not follow it any more. And how should i notice your script, when it never applies to my packages? ;-) Note that there is a tradeoff here: I really started the stabilizations after I've noticed how many bugs are fixed in ~arch that still affect stable, but the fixing version didn't get stabilized. This is the downside of an opt-in approach, since inactive maintainers are not going to opt-in. Finally, everyone from metadata.xml is CC-ed. There is no trying a different maintainer - all of them are there since day one. trying a different maintainer did mean re-assigning the package, when a maintainer is gone/inactive Please let me know if you still have concerns - ideally back them with data and actual cases showing problems (or scenarios that can reasonably be likely) instead of just saying it _might_ lead to breakages. Anything _might_ lead to breakages, including taking no action here and allowing bugs to be not fixed for stable. :) Give me the needed amount of time to create such data, dont miss the motivation for such project and i may do it. ;-) Some show cases: When a maintainer wants to stable at a later point in time or another version and keeps the bug open to re-use it, he would suddenly get your suggested version stable, also he did explicitly not give his go and did not add arches. And if a maintainer does not respond for a certain amount of time, i would not take it as a sign for a package to be stable, but instead of a sign, that the package will need a new maintainer, who can then check for the best fit for a stable candidate. After all, the latest version may be the upstream development branch, while latest stable already follows upstream stable branch. So creating stable bugs with your above requirements looks ok, the point i have a problem with is still the opt-out setting. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
Rick Zero_Chaos Farina schrieb: On 05/21/2013 09:20 AM, Markos Chandras wrote: On 21 May 2013 13:21, Thomas Sachau to...@gentoo.org wrote: Paweł Hajdan, Jr. schrieb: Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. Paweł Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. -- Thomas Sachau Gentoo Linux Developer If you don't read your bugmail in 30 days then that is a different problem. I like the way Paweł handles this at the moment. 30 days is enough time for active maintainers to object. We just can't afford waiting months for inactive maintainers to act. Who said, that bugmail is ignored? Repeating myself, it may be accidently deleted by the dev or some software (hint: spam filters), it may actually even be ignored to re-use the bug later. Since i dont remember even seing a hint for the will stable in 30 days without objection, the arch addition is even more a bad surprise for a maintainer. I have to agree very strongly with this sentiment. If I'm ignoring my bugmail for 30 days and there are no (new) active bugs against the package it should be stabilized. The only time this shouldn't happen is if there is a bug in the new version which isn't present in the old version. See above We all need to learn to either be more responsive or stop complaining when other people fix our stuff. If you don't respond to your bugmail in 30 days then active maintainer is a bit of a stretch unless you have devaway setup. So with a devaway setup pointing to another dev, which wont get CCed nor asked, so cannot deny it, the package would become stable too, even when it should not. ;-) -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
Am Mittwoch, 22. Mai 2013, 01:43:15 schrieb Thomas Sachau: Who said, that bugmail is ignored? Repeating myself, it may be accidently deleted by the dev or some software (hint: spam filters), it may actually even be ignored to re-use the bug later. Since i dont remember even seing a hint for the will stable in 30 days without objection, the arch addition is even more a bad surprise for a maintainer. Yep. Sounds like this is another case of maintainer does not read -dev ml, pops up half a year after policies become active, and starts complaining. Come on, I also have a hard time with this list. However, I'm at least skimming the thread titles. (And for stuff like OMG systemd killed my kittens my mail client has a nice ignore thread feature.) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/21/2013 07:43 PM, Thomas Sachau wrote: Rick Zero_Chaos Farina schrieb: On 05/21/2013 09:20 AM, Markos Chandras wrote: On 21 May 2013 13:21, Thomas Sachau to...@gentoo.org wrote: Paweł Hajdan, Jr. schrieb: Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. Paweł Uhm, automagic stabilization without maintainer ok? This sounds like a bad idea. Doing a batch CC-ing after maintainer gave his ok or anything similar, which starts, when someone actually aproved the stable going is all ok, but doing this automaticly may get packages become stable, which are not intended to become so and should have never been there. -- Thomas Sachau Gentoo Linux Developer If you don't read your bugmail in 30 days then that is a different problem. I like the way Paweł handles this at the moment. 30 days is enough time for active maintainers to object. We just can't afford waiting months for inactive maintainers to act. Who said, that bugmail is ignored? Repeating myself, it may be accidently deleted by the dev or some software (hint: spam filters), it may actually even be ignored to re-use the bug later. Since i dont remember even seing a hint for the will stable in 30 days without objection, the arch addition is even more a bad surprise for a maintainer. With respect, if a dev is having their bugzie mail deleted by a spam filter they need to get that fixed, and I should hope accidental deletion is a rare enough event as to not play a significant role here. I do, however, completely agree that there should be some way to leave the bug open and state that it will be stabled later. Would a comment trigger this in the script? That seems semi-sane. If the maintainer wanted to stabilize things they would cc arches, any other comment could likely be understood to mean don't auto-stable this. I have to agree very strongly with this sentiment. If I'm ignoring my bugmail for 30 days and there are no (new) active bugs against the package it should be stabilized. The only time this shouldn't happen is if there is a bug in the new version which isn't present in the old version. See above We all need to learn to either be more responsive or stop complaining when other people fix our stuff. If you don't respond to your bugmail in 30 days then active maintainer is a bit of a stretch unless you have devaway setup. So with a devaway setup pointing to another dev, which wont get CCed nor asked, so cannot deny it, the package would become stable too, even when it should not. ;-) Specifically I meant we should exempt packages with a maintainer on devaway from the auto-stabilization. Please understand I don't mean to suggest that this process is perfect, but it is valuable and it seems people are willing to improve it where possible so I for one would love the help getting more things stabilized. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRnD+AAAoJEKXdFCfdEflKpYAP/Am/3l/94jNFmWld8mn7QPes IYN+GMYOxBw1s/ZXCrPHybloq8a3os49Y50710xxqsKLjK/JnlGpYohl3IQxZdlL +9aS2r/HubRc50dDbXNjXByzMRjVYY0ej/c7lLEk3G3AfxD35AD3gxXerxXZ5j4I jRyiQ3Ee74ramZbam+iSAs4dg91uM1aMPgpNU0UySa8Lj9JquJ4JZeLGX/gKgA6n NcBnTN+8fWr8ketsPSnfrHlnECeYhLDw3dMNB4d5L8p8vzk8ronHIG23/dxNZvst 93LTUGPPJBirTBcxS0SEDWp6kOyhHeO7jyCYEOIvFn8RO/5gu7bsmaL734HRZx41 xl89Tvbw9aA2EAZKFhoyc6vv4/L+Put82A3GiPFYh896L3iZmP7xIFYfeUSR7aTo rKpIshaRNS0TJIyGgI0eWSLeR1bvi3WF0heAHfMYOzbdx54Is3GpIbhAjww3xbDq oRppTnCZAD/Y3WmdgaUosKIBzRBOFuZOGlAbD/2HvQB5KPvp8cgSlFhs8G7zx7RW II9frccgLSY5A7SAwhSRIhU8/3uAVpHHq6dfvWtuVZbEY6SP3sD1xblwituqFcqz WPLXo0uYF1GlkZHqIK/ZhmeJMXggstnQP0q2H1PNzEm2SlYcToHVizaeZAs6i4hd q1OrR+URh7KqM5GCzYaA =vISF -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
Le dimanche 19 mai 2013 à 17:00 -0700, Paweł Hajdan, Jr. a écrit : On 5/19/13 6:40 AM, Jeroen Roovers wrote: Private messages and public comments through bugzilla are so far ignored, it seems, so let's try a venue where it's sure to cause a flamewar instead. My apologies for the inconvenience. Hey Jeroen, apologies if I have ignored any of your feedback. I'm indeed behind on bugmail (5000 unread emails, how about that?). That would explain why you're still filling gnome stabilization bugs while we replied many times we don't want them in their current form ? I do read mailing list traffic and direct e-mail though. We agreed a little while ago that bug Summaries should start with an atom, if possible, and explain the action later. Could you refer me to the part where we agreed and why? I'm actually happy to make changes that are useful for people, but without a good rationale and an _actual_ consensus someone else will inevitably come and says he likes the old way better. This was discussed on the mailing list a couple of times. Last big thread related to this was automatic bug assignment iirc. This generally needs to go first so sorting by summary shows your packages in order and you have a chance to see this part of the summary in bugzilla (with version optionally), the rest of the summary line is imho less important when working through the web interface. Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. I'll repeat gnome team position here: We do not want automated stabilization requests. We handle so many packages that having individual bug reports is driving arch teams and us crazy. We have our own set of scripts to do batch stabilization bug reports. They were designed with arch teams so that it does not generate too much load on them. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] robo-stable bugs
On Sun, 19 May 2013 15:40:27 +0200 Jeroen Roovers j...@gentoo.org wrote: Private messages and public comments through bugzilla are so far ignored, it seems, so let's try a venue where it's sure to cause a flamewar instead. My apologies for the inconvenience. Since you are the BW lead, I have followed your suggestion and done so since; but as I stated last time, there's no indication for others to follow this as far I can see. Maybe there is, then please show us. On Sat, 18 May 2013 21:08:53 + bugzilla-dae...@gentoo.org wrote: DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To comment on this bug, please visit: https://bugs.gentoo.org/show_bug.cgi?id=470392 Bug ID: 470392 Summary: Please stabilize =dev-libs/libconfig-1.4.9-r1 We agreed a little while ago that bug Summaries should start with an atom, if possible, and explain the action later. Also, robotically filing thousands of bugs and making them say please every time isn't going to endear anyone to your cause. So do something like this: cat/pkg-version stabilisation request This is missing a reference URL or at least the ML thread subject; last time I asked, I didn't got either and wasn't able to find this in a reasonable amount of time. I find some irrelevant policy discussions but nothing that indicates the order in the summary. There are some developers that tend to point to history this way, they don't take into account how though it can be to search these threads if you don't use the wrong keywords to find the wrong subject. In 5 years from now, I don't think anyone is going to find robo-stable bugs searching for please stabilize, bug summary order or any other thing along those lines. I could read the whole history, but that keeps me from contributing. URL: http://packages.gentoo.org/package/dev-libs/libconfig? arches=linux Is this URL useful to include, or did you just want to abuse every last feature found in pybugz? Wouldn't maintainers already know where to find this kind of information? Who do you think is your audience? +1 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?) 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. 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. The only case where I see them as useful is when people raise them to a higher priority for bugs that are really more important than the average bug, it makes them stand out in their list. We should standardize these in a way we don't have to memorize what they mean for every different type of bug, as that's the only way it is really going to make these fields make much more sense than something we tend to normalize and forget about. Why are bugs that block users from being able to use the package given a normal priority? Is it OK to stabilize =dev-libs/libconfig-1.4.9-r1 ? If so, please CC all arches which have stable keywords for older versions of this package and add STABLEREQ keyword to the bug. My e-mail editor is messing up the line endings here, but your messages already include double newlines - on bugzilla web pages as well as in the e-mail it sends, so this is your broken pybugz script again, I reckon? That's so we can print the bug mail and write notes in between. =) 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. Maintainer(s) and arch team member(s) blamed me for setting this. :( -- 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] robo-stable bugs
On 5/20/13 5:10 AM, Gilles Dartiguelongue wrote: That would explain why you're still filling gnome stabilization bugs while we replied many times we don't want them in their current form ? If you're still getting bugs from my script it's a bug in my script, sorry about that. Could you post the most recent example of such a bug? The script applies exclusion list into account since http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=3c20e14c939bf0efa495dead6243f8035d699b86 (Feb 2013) and gnome is part of the exclusion list since http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=f63c885b61c46482781e22fb6f117f110eada79d (Aug 2012). This generally needs to go first so sorting by summary shows your packages in order and you have a chance to see this part of the summary in bugzilla (with version optionally), the rest of the summary line is imho less important when working through the web interface. This makes sense. I'll post an update when I make this simple change to the script. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
On Mon, May 20, 2013 at 11:29 AM, Tom Wijsman tom...@gentoo.org wrote: This is missing a reference URL or at least the ML thread subject; last time I asked, I didn't got either and wasn't able to find this in a reasonable amount of time. I find some irrelevant policy discussions but nothing that indicates the order in the summary. Tend to agree, but rather than focusing on figuring out who messed up/etc, let's just move forward. The proposed placement of PVs at the start of the subject line makes logical sense, so we might as well do it. Short of making an automated bug reporting policy I'm not sure how to better document things. I agree that it is easy to miss stuff in list archives. Bottom line is people shouldn't take this stuff personally - just improve and move on. 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. But, since we're not getting paid it really is more of a communication/organization tool. At work when we mark bugs high we expect them to get fixed, since the devs are paid to work on what we want them to work on, and if that means leaving the blocker alone while making the splash screen look prettier that's management's prerogative. If we do want to have two fields, then the one should be more of a factual statement (is it an improvement, something that makes the package unusable for some users, a regression, something that makes the package unusable for all users, removal of a blocker, etc - roughly in increasing severity), and the other a true priority (H/M/L - which is at the discretion of the maintainer, but perhaps set initially based on guidelines in order to help them out). Rich
Re: [gentoo-dev] robo-stable bugs
On Mon, May 20, 2013 at 05:29:43PM +0200, Tom Wijsman wrote: cat/pkg-version stabilisation request This is missing a reference URL or at least the ML thread subject; last time I asked, I didn't got either and wasn't able to find this in a reasonable amount of time. I find some irrelevant policy discussions but nothing that indicates the order in the summary. http://www.gossamer-threads.com/lists/gentoo/dev/173889?do=post_view_threaded The thread does mention that atoms should be first, as well. It also makes sorting and viewing much easier (all related atoms are together). 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. It would be nice if these could be better documented. 'enhancement' gets the most use from me for oldnet/openrc feature requests. 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. Maintainer(s) and arch team member(s) blamed me for setting this. :( I think the keyword should be there. If anybody else things the keyword should NOT be there, I'd like to hear from them here. Additionally, there used to be an old webapp where you could select by dev/herd and see how many days every package with that dev/herd had been in ~arch for all given arches. Something like that easily usable would be handy again, as a stop-gap to automatic stabilization. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] robo-stable bugs
On Mon, 20 May 2013 13:15:09 -0400 Rich Freeman ri...@gentoo.org wrote: Tend to agree, but rather than focusing on figuring out who messed up/etc, let's just move forward. The link would be handy to refer to when we need to educate future people; but anyhow, someone else responded something relevant just now. Regarding who, it's not a single person; the majority of bugs that _aren't_ automatically filed show this problem, multiple people do so. Nobody did bad, there's just a lack of communication *from both sides*. Short of making an automated bug reporting policy I'm not sure how to better document things. I agree that it is easy to miss stuff in list archives. Bottom line is people shouldn't take this stuff personally - just improve and move on. Yeah, imho, bots and scripts that run mass actions against anything in the Gentoo infrastructure should be reviewed or be made according to such policy. I haven't seen a review of the last mass actions being, and I don't think they are implemented according to certain standards. Some thoughts: - Rate limiting. - Skim the list the script applies to for exceptions. - Run a small enough subset as a test before running the entire thing. 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. Probably, how would such field work? One field being just priority? But, since we're not getting paid it really is more of a communication/organization tool. At work when we mark bugs high we expect them to get fixed, since the devs are paid to work on what we want them to work on, and if that means leaving the blocker alone while making the splash screen look prettier that's management's prerogative. Yeah, and here at Gentoo the version bumps are attractive; until there are no more version bumps to do, then we often just pick a random bug where we should probably pick one of the more important ones. If we do want to have two fields, then the one should be more of a factual statement (is it an improvement, something that makes the package unusable for some users, a regression, something that makes the package unusable for all users, removal of a blocker, etc - roughly in increasing severity), and the other a true priority (H/M/L - which is at the discretion of the maintainer, but perhaps set initially based on guidelines in order to help them out). Yes, bringing more meaning into them is what would be nice to see. -- 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] robo-stable bugs
On Mon, 20 May 2013 18:00:49 + Robin H. Johnson robb...@gentoo.org wrote: http://www.gossamer-threads.com/lists/gentoo/dev/173889?do=post_view_threaded The thread does mention that atoms should be first, as well. It also makes sorting and viewing much easier (all related atoms are together). Thanks. 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. Maintainer(s) and arch team member(s) blamed me for setting this. :( I think the keyword should be there. If anybody else things the keyword should NOT be there, I'd like to hear from them here. From what I heard, this keyword is used to see whether a stabilization request bug is an actual stabilization request. Adding the keyword without CC-ing arches clutters the bug list that tracks all stabilazion request bugs since there would then be bugs that the arches can not take any action on. Of course arches use the CC feature for tracking these, but there are persons tracking the entire list too to pay attention to bugs that have been forgotten about; or persons whom have access to multiple arches and are in multiple arch teams may also prefer to use the full list instead of depending on the individual CC mails. But that's just my limited view on this, the relevant maintainers and arch team members that request this can probably shed a better light on the need for STABLEREQ to only be placed by the maintainer and not by the reporter or bug wrangler. Additionally, there used to be an old webapp where you could select by dev/herd and see how many days every package with that dev/herd had been in ~arch for all given arches. Something like that easily usable would be handy again, as a stop-gap to automatic stabilization. We have `iamlate` for this in app-portage/gentoolkit-dev. -- 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] robo-stable bugs
Private messages and public comments through bugzilla are so far ignored, it seems, so let's try a venue where it's sure to cause a flamewar instead. My apologies for the inconvenience. On Sat, 18 May 2013 21:08:53 + bugzilla-dae...@gentoo.org wrote: DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To comment on this bug, please visit: https://bugs.gentoo.org/show_bug.cgi?id=470392 Bug ID: 470392 Summary: Please stabilize =dev-libs/libconfig-1.4.9-r1 We agreed a little while ago that bug Summaries should start with an atom, if possible, and explain the action later. Also, robotically filing thousands of bugs and making them say please every time isn't going to endear anyone to your cause. So do something like this: cat/pkg-version stabilisation request URL: http://packages.gentoo.org/package/dev-libs/libconfig? arches=linux Is this URL useful to include, or did you just want to abuse every last feature found in pybugz? Wouldn't maintainers already know where to find this kind of information? Who do you think is your audience? 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?) 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. Is it OK to stabilize =dev-libs/libconfig-1.4.9-r1 ? If so, please CC all arches which have stable keywords for older versions of this package and add STABLEREQ keyword to the bug. My e-mail editor is messing up the line endings here, but your messages already include double newlines - on bugzilla web pages as well as in the e-mail it sends, so this is your broken pybugz script again, I reckon? 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. jer
Re: [gentoo-dev] robo-stable bugs
On Sun, May 19, 2013 at 3:40 PM, Jeroen Roovers j...@gentoo.org wrote: On Sat, 18 May 2013 21:08:53 + bugzilla-dae...@gentoo.org wrote: DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To comment on this bug, please visit: https://bugs.gentoo.org/show_bug.cgi?id=470392 Bug ID: 470392 Summary: Please stabilize =dev-libs/libconfig-1.4.9-r1 We agreed a little while ago that bug Summaries should start with an atom, if possible, and explain the action later. Also, robotically filing thousands of bugs and making them say please every time isn't going to endear anyone to your cause. So do something like this: cat/pkg-version stabilisation request When/where did that happen? 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, good point. It makes sense to me that this bug is strictly an enhancement (e.g. more like a feature than like a bug), but that's more a bug type than a 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. 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? Sure, but in the case of mass-filing stabilization bugs, optimizing for maintainers makes more sense to me. Cheers, Dirkjan
Re: [gentoo-dev] robo-stable bugs
On 05/19/2013 02:40 PM, Jeroen Roovers wrote: Private messages and public comments through bugzilla are so far ignored, it seems, so let's try a venue where it's sure to cause a flamewar instead. My apologies for the inconvenience. fwiw the current situation works for me quite well. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] robo-stable bugs
TL;DR: I like the stabilization bugs as they are. Summary: Please stabilize =dev-libs/libconfig-1.4.9-r1 We agreed a little while ago that bug Summaries should start with an atom, if possible, and explain the action later. Also, robotically filing thousands of bugs and making them say please every time isn't going to endear anyone to your cause. So do something like this: cat/pkg-version stabilisation request No opinion about the order of things, that's imho nitpicking. The Please does not hurt anyone. URL: http://packages.gentoo.org/package/dev-libs/libconfig? arches=linux Is this URL useful to include, or did you just want to abuse every last feature found in pybugz? Wouldn't maintainers already know where to find this kind of information? Who do you think is your audience? It's convenient, although redundant. Why is it a problem to have the URL there? Maybe someone finds it useful. 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?) That's how it has been done for a while now with stablerequests. You're clearly an oldtimer. :) 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. Well, that was as far as I can remember a deliberate decision- maintainer action should be set STABLEREQ keyword and CC arches. Probably the keyword could already be preset, though. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
On 5/19/13 6:40 AM, Jeroen Roovers wrote: Private messages and public comments through bugzilla are so far ignored, it seems, so let's try a venue where it's sure to cause a flamewar instead. My apologies for the inconvenience. Hey Jeroen, apologies if I have ignored any of your feedback. I'm indeed behind on bugmail (5000 unread emails, how about that?). I do read mailing list traffic and direct e-mail though. We agreed a little while ago that bug Summaries should start with an atom, if possible, and explain the action later. Could you refer me to the part where we agreed and why? I'm actually happy to make changes that are useful for people, but without a good rationale and an _actual_ consensus someone else will inevitably come and says he likes the old way better. URL: http://packages.gentoo.org/package/dev-libs/libconfig? arches=linux Is this URL useful to include, or did you just want to abuse every last feature found in pybugz? Wouldn't maintainers already know where to find this kind of information? Who do you think is your audience? My audience is a developer who doesn't have lots of time. It's not so much about not knowing at all where to look for it, but being able to do so really quickly. For me (maybe not so for other people - fine), it's much quicker to click a link than to copy-paste package name to either a URL or eshowkw or anything else, especially with more tricky package names like: app-emulation/open-vm-tools-2012.03.13.651368 (long version number) dev-perl/LWP-Protocol-https-6.30.0 (case variations) dev-php/PEAR-Crypt_RC4-1.0.3 (underscore vs dash variations) Please let me know if there is any _downside_ of having the URL, especially now that you know the upside. :) 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?) What is your constructive alternative to this? 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. AFAIK this is the default setting. What is your constructive alternative? I'm actually serious - if you have specific changes in mind, I'd be happy to make them if I see the rationale. My e-mail editor is messing up the line endings here, but your messages already include double newlines - on bugzilla web pages as well as in the e-mail it sends, so this is your broken pybugz script again, I reckon? Fixed: http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=3d2d92a6537bec6be9c39ac113eb88f85faca315 Thank you for reporting this. 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. This is more tricky. If there is a consensus about STABLEREQ keyword, I'd be happy to add it. I vaguely remember some past controversies about it (or maybe it was actually same as what you're suggesting here). Remember this is supposed to _help_ Gentoo. You can opt out of the bugs (there is a package name and maintainer name regex in the script). You don't need to hunt them down - if you do nothing another script will just CC arches after 30 days. Paweł signature.asc Description: OpenPGP digital signature
