[gentoo-dev] robo-stable bugs

[gentoo-dev] robo-stable bugs

[Jeroen Roovers]

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 +0000
bugzilla-daemon@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

[gentoo-dev] Re: robo-stable bugs

[Michael Palimaka]

On 19/05/2013 23:40, Jeroen Roovers wrote:
>>                  OS: Linux
>>              Status: CONFIRMED
>>            Severity: enhancement
>
> Is a stabilisation an enhancement per se?
Usually I think so yes. If it is an urgent stabilisation there is 
priority field.

> If all stabilisations are
> enhancements, then why isn't Severity set to Normal instead? (What is
> an enhanced severity to begin with, Mozilla?)
According to the Bugzilla docs: "Severity - How severe the bug is, or 
whether it's an enhancement." so there is no such thing as an "enhanced 
severity".

>>            Priority: Normal
>
> This is where you probably wanted to set something similar to
> Enhancement above, but again you probably shouldn't. Normal
> stabilisation bugs are normal, not less than normal.
Why should enhancement go in the priority field, when it does not 
presently exist there but does exist in the severity field?

> Also, your script does not set the STABLEREQ keyword. People are having
> to hunt down your robo-stabilisation requests and add it themselves.
> You should just do it yourself or turn your script off.
According to the bug wrangler docs STABLEREQ should be handled by the 
maintainer. Why should there be a difference whether a user or a dev is 
requesting stabilisation?

Re: [gentoo-dev] robo-stable bugs

[Dirkjan Ochtman]

On Sun, May 19, 2013 at 3:40 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Sat, 18 May 2013 21:08:53 +0000
> bugzilla-daemon@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

[Markos Chandras]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1848 bytes --]


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 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] robo-stable bugs

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 3590 bytes --]

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ł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Gilles Dartiguelongue]

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 <eva@gentoo.org>
Gentoo

Re: [gentoo-dev] robo-stable bugs

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

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ł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] robo-stable bugs

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

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ł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 579 bytes --]

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 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

"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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Chí-Thanh Christopher Nguyễn]

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

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Jeroen Roovers]

On Tue, 21 May 2013 15:32:25 +0200
Thomas Sachau <tommy@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

[Markos Chandras]

On 21 May 2013 13:21, Thomas Sachau <tommy@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

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

Markos Chandras schrieb:
> On 21 May 2013 13:21, Thomas Sachau <tommy@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] robo-stable bugs

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

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ł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Markos Chandras]

On 21 May 2013 19:32, "Paweł Hajdan, Jr." <phajdan.jr@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

[Alexis Ballier]

On Tue, 21 May 2013 20:51:52 +0100
Markos Chandras <hwoarang@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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On 5/21/13 1:17 PM, Alexis Ballier wrote:
> On Tue, 21 May 2013 20:51:52 +0100 Markos Chandras
> <hwoarang@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ł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 668 bytes --]

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 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Alexis Ballier]

On Tue, 21 May 2013 13:46:18 -0700
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 5/21/13 1:17 PM, Alexis Ballier wrote:
> > On Tue, 21 May 2013 20:51:52 +0100 Markos Chandras
> > <hwoarang@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.

[gentoo-dev] Re: robo-stable bugs

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On Tue, 21 May 2013 16:17:30 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> On Tue, 21 May 2013 20:51:52 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
> > I'd rather not see this process changes, because it has helped
> > bringing the stable tree up2date. However, given that *a few* people
> > don't like it, I suggest you don't file bugs for packages owned by
> > them.
> 
> +1
> 
> I am (was) unhappy with some corner cases that used to happen (like
> bug #428968 ) but overall I consider it very useful; I'm even
> becoming more lazy and do not look for stable candidates because I know
> some day I'll have an automated request :P

Yes my laziness won out against any objections too. :)


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

"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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 530 bytes --]

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 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] robo-stable bugs

[vivo75]

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.

[gentoo-dev] Re: robo-stable bugs

[Michael Palimaka]

On 22/05/2013 19:22, vivo75@gmail.com wrote:
> On 05/21/13 23:38, Andreas K. Huettel wrote:
>> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau:
>>> And if a maintainer is not responding within 30 days, you can ping him
>>> or, without a response, try to get a different maintainer. Just assuming
>>> that a stable request is ok without a maintainer response is really not
>>> a good idea.
>> If none of the listed maintainers responds to a bug in 30 days in any way, the
>> package is effectively unmaintained.
>>
> And thus its risky to mark it stable.
>
>
That's why we have arch teams in the first place, to test beforehand.

Re: [gentoo-dev] Re: robo-stable bugs

[vivo75]

On 05/22/13 11:43, Michael Palimaka wrote:
> On 22/05/2013 19:22, vivo75@gmail.com wrote:
>> On 05/21/13 23:38, Andreas K. Huettel wrote:
>>> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau:
>>>> And if a maintainer is not responding within 30 days, you can ping him
>>>> or, without a response, try to get a different maintainer. Just
>>>> assuming
>>>> that a stable request is ok without a maintainer response is really
>>>> not
>>>> a good idea.
>>> If none of the listed maintainers responds to a bug in 30 days in
>>> any way, the
>>> package is effectively unmaintained.
>>>
>> And thus its risky to mark it stable.
>>
>>
> That's why we have arch teams in the first place, to test beforehand.
>
>
The risky part is about the after, not the before, to avoid the risks
arch teams should keep the package working *after* it has stabilized.
Seem to be a good case for those things that need to be evaluated case
by case and could not be written in stone.

[gentoo-dev] Re: robo-stable bugs

[Michael Palimaka]

On 22/05/2013 20:07, vivo75@gmail.com wrote:
> On 05/22/13 11:43, Michael Palimaka wrote:
>> On 22/05/2013 19:22, vivo75@gmail.com wrote:
>>> On 05/21/13 23:38, Andreas K. Huettel wrote:
>>>> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau:
>>>>> And if a maintainer is not responding within 30 days, you can ping him
>>>>> or, without a response, try to get a different maintainer. Just
>>>>> assuming
>>>>> that a stable request is ok without a maintainer response is really
>>>>> not
>>>>> a good idea.
>>>> If none of the listed maintainers responds to a bug in 30 days in
>>>> any way, the
>>>> package is effectively unmaintained.
>>>>
>>> And thus its risky to mark it stable.
>>>
>>>
>> That's why we have arch teams in the first place, to test beforehand.
>>
>>
> The risky part is about the after, not the before, to avoid the risks
> arch teams should keep the package working *after* it has stabilized.
> Seem to be a good case for those things that need to be evaluated case
> by case and could not be written in stone.
>
>
I am confused as to what you are proposing. Do you want arch teams to 
continually test packages that are already in stable to make sure they 
haven't broken somehow?

Re: [gentoo-dev] Re: robo-stable bugs

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

Michael Palimaka schrieb:
> On 22/05/2013 20:07, vivo75@gmail.com wrote:
>> On 05/22/13 11:43, Michael Palimaka wrote:
>>> On 22/05/2013 19:22, vivo75@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

[gentoo-dev] Re: robo-stable bugs

[Michael Palimaka]

On 22/05/2013 20:41, Thomas Sachau wrote:
> Michael Palimaka schrieb:
>> On 22/05/2013 20:07, vivo75@gmail.com wrote:
>>> On 05/22/13 11:43, Michael Palimaka wrote:
>>>> On 22/05/2013 19:22, vivo75@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.

Re: [gentoo-dev] Re: robo-stable bugs

[vivo75]

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, vivo75@gmail.com wrote:
>>>> On 05/22/13 11:43, Michael Palimaka wrote:
>>>>> On 22/05/2013 19:22, vivo75@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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/05/13 07:16 AM, vivo75@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, vivo75@gmail.com wrote:
>>>>> On 05/22/13 11:43, Michael Palimaka wrote:
>>>>>> On 22/05/2013 19:22, vivo75@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

[Jeroen Roovers]

On Wed, 22 May 2013 09:03:43 -0400
Ian Stakenvicius <axs@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

[Ian Stakenvicius]

-----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
> <axs@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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/05/13 06:07 AM, vivo75@gmail.com wrote:
> On 05/22/13 11:43, Michael Palimaka wrote:
>> On 22/05/2013 19:22, vivo75@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] robo-stable bugs

[Rich Freeman]

On Wed, May 22, 2013 at 5:22 AM, vivo75@gmail.com <vivo75@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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/21/2013 09:20 AM, Markos Chandras wrote:
> On 21 May 2013 13:21, Thomas Sachau <tommy@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

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]

Rick "Zero_Chaos" Farina schrieb:
> On 05/21/2013 09:20 AM, Markos Chandras wrote:
>> On 21 May 2013 13:21, Thomas Sachau <tommy@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 899 bytes --]

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 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Rick "Zero_Chaos" Farina]

-----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 <tommy@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

[Ian Stakenvicius]

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

[Rick "Zero_Chaos" Farina]

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

[Ian Stakenvicius]

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

[Ian Stakenvicius]

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

[Markos Chandras]

On 23 May 2013 19:11, Ian Stakenvicius <axs@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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/05/13 02:40 PM, Markos Chandras wrote:
> On 23 May 2013 19:11, Ian Stakenvicius <axs@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

[Rich Freeman]

On Thu, May 23, 2013 at 2:49 PM, Ian Stakenvicius <axs@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

[Ian Stakenvicius]

-----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 <axs@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, the flipside

[Markos Chandras]

On 23 May 2013 19:49, Ian Stakenvicius <axs@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 <axs@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, the flipside

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/05/13 04:14 PM, Markos Chandras wrote:
> On 23 May 2013 19:49, Ian Stakenvicius <axs@gentoo.org> wrote: On
> 23/05/13 02:40 PM, Markos Chandras wrote:
>>>> On 23 May 2013 19:11, Ian Stakenvicius <axs@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

[Ian Stakenvicius]

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Jeroen Roovers]

On Wed, 22 May 2013 08:53:06 -0400
Ian Stakenvicius <axs@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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

On 05/22/2013 11:00 AM, Jeroen Roovers wrote:
> On Wed, 22 May 2013 08:53:06 -0400
> Ian Stakenvicius <axs@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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Ian Stakenvicius]

-----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
>> <axs@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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]

On Sun, 19 May 2013 15:40:27 +0200
Jeroen Roovers <jer@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 +0000
> bugzilla-daemon@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Rich Freeman]

On Mon, May 20, 2013 at 11:29 AM, Tom Wijsman <TomWij@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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]

On Mon, 20 May 2013 13:15:09 -0400
Rich Freeman <rich0@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: robo-stable bugs

[Duncan]

Rich Freeman posted on Mon, 20 May 2013 13:15:09 -0400 as excerpted:

>> Severity and Priority on the Gentoo Bugzilla have always been weird to
>> me; I would love to hear from someone who is actually using either of
>> those to sort their bugs and using them happily, because the
>> inconsistency applied by different people is making a mess of them.
> 
> I suspect we could just get by with one field.
> 
> Typically at work the severity reflects impact of a bug (the effects it
> has on customers), and the priority reflects management direction on
> what developers should be working on.  Our fields are a bit of a
> mish-mash of both, and of course maintainers can generally ignore or
> work on bugs in any order with little impact on their salary.  It does
> make sense to distinguish between a bug holding up the next gcc release
> (scheduled a week in the future) and adding a desktop entry to a package
> that otherwise works just fine.

As a user, I've understood:

* Severity is something the user/filer can use.

* Priority is strictly for maintainers/teams if they want to use it, NOT 
the user/filer (unless it's a maintainer filed bug).

Thus there's reason to have two separate fields, one that's specifically 
reserved for the maintainer, one for the user, that a maintainer can 
choose to ignore if they decide to.

Even so, if there's no known-approved reason to set severity, a user 
should just leave it alone.  That means users unfamiliar with gentoo's 
bugzilla should just leave it alone.

Here, I only use severity in a few cases, generally the exception rather 
than the rule.  

* If it's an enhancement I mark it as such, and expect maintainer bug 
priority ranked less urgent as a result.  The *.desktop file example 
someone mentioned goes here, as do, arguably, changes such as the md 
initscript improvements I filed some years ago (tho those could equally 
arguably be left as normal by the user and let the maintainer decide, I'd 
certainly not argue a maintainer changing that to/from enhancement).

* If the bug has system-wide or arch-class-wide (all ~arch, for instance) 
implications, I'll sometimes up severity accordingly, with a note in the 
text explaining my reasoning.  Toolchain or base-system bugs that prevent 
normal boot or system upgrade arguably fit here, especially if they're on 
a recently (say a day) unmasked or announced to be unmasked package with 
arch-class-wide implications, where an immediate remask might be 
appropriate until the situation can be resolved.

* Also, arugably many security bugs could get severity-upgraded, altho 
with security handled separately on gentoo, I'd discourage that unless 
again it's something like toolchain or base-system, thus fitting the 
above system-wide condition.


Based on the above, I'd suggest that:

* The priority field should be restricted to devs (if it's not already), 
and that devs who misuse the field on packages they don't maintain be 
treated accordingly.

* The severity field is arguably a candidate for "first gentoo 
privilege", restricted for ordinary users, but with a moderately liberal 
"on-request" policy, for users who have demonstrated consistent 
responsible bug filing, on gentoo bugzy at least, but also those who can 
point to bugs filed elsewhere in the community, package upstream and peer-
distro maintainers, etc.

Of course the "first gentoo privilege" is requisite on the appropriate 
infrastructure being in place to handle it, and would arguably be 
settable by anyone with higher gentoo bugzilla privs.  If implemented, 
constructing an initial whitelist might be in order.  A note in gentoo 
bugzy suggesting that users can request "severity privilege" in any filed 
bug, should they believe they can handle it responsibly, could be 
appropriate as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: robo-stable bugs

[Jeroen Roovers]

On Tue, 21 May 2013 00:46:22 +0000 (UTC)
Duncan <1i5t5.duncan@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

[gentoo-dev] Re: robo-stable bugs

[Duncan]

Jeroen Roovers posted on Wed, 22 May 2013 17:21:46 +0200 as excerpted:

> On Tue, 21 May 2013 00:46:22 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> As a user, I've understood:
>> 
>> * Severity is something the user/filer can use.
> 
> So when Chromium doesn't compile on your machine, you set it as a
> Blocker, and then it gets reverted to Normal because it works fine for
> the other 99,9%.

Well, I chose to put the big bullet-points at the top and the caveats 
(with which you agreed) below.  The caveat in this case being that even 
still a normal user shouldn't be setting it, and I even proposed making 
that the first level of "gentoo bugzilla privilege" people could get, 
thus restricting it for the general user.

> Individual users are probably not best suited to
> discover the scope of a bug report, let alone the actual bug, if there
> is one. If the Severity does not get reverted to Normal, then we can
> safely assume it's being completely ignored.

I'd not agree that it's safe to assume, but it certainly could be the 
case.

> The interpretation of Severity is highly dependent on the type of bug
> report. It's already diverting strongly between stabilisation requests,
> security vulnerabilities and changes to documentation. The meaning of
> the field thusly changes according to the Product/Component and other
> fields.

True.

>> Even so, if there's no known-approved reason to set severity, a user
>> should just leave it alone.  That means users unfamiliar with gentoo's
>> bugzilla should just leave it alone.
> 
> Agreed.

=:^)

>> * If it's an enhancement I mark it as such, and expect maintainer bug
>> priority ranked less urgent as a result.  The *.desktop file example
>> someone mentioned goes here,
> 
> What if a bad/missing .desktop file stops you from running an app
> through your DM/another app trying to find an appropriate program to
> open a file in?

It's still an enhancement.  If it were /that/ important to the app in 
general, it'd be shipped by upstream.  It not being shipped by upstream 
means (at minimum) they don't care enough to have made it a priority, and 
that existing general functionality isn't affected, which means the 
generally lower priority of "enhancement" fits, because that's what it 
/is/, an "enhancement, an /added/ feature in this case for better desktop 
integration.

It's certainly more an enhancement than a bug with an existing feature, 
the default case, thus the name "bugzilla".

>> * If the bug has system-wide or arch-class-wide (all ~arch, for
>> instance) implications, I'll sometimes up severity accordingly, with a
>> note in the text explaining my reasoning.  Toolchain or base-system
>> bugs that prevent normal boot or system upgrade arguably fit here,
>> especially if they're on a recently (say a day) unmasked or announced
>> to be unmasked package with arch-class-wide implications, where an
>> immediate remask might be appropriate until the situation can be
>> resolved.
> 
> What if your initial analysis completely misses the mark? Then you end
> up with an INVALID Blocker with one or more devs investigating hours in
> a user error. How did setting Severity help here?

In the "first privilege" scenario I suggested, ordinary users wouldn't 
have that ability, and if those who /do/ have that ability abuse it 
consistently, well, it's a privilege not a right, and it gets revoked as 
such.

Which would tend to make users with the privilege /very/ cautious about 
setting it, since it could cause a privilege revoke.

> In conclusion, setting Severity can only be properly done after an
> actual bug has been appreciated, not at the time you file the bug
> report.

With the bugs I file where I change it, I've confident enough in the leg-
work I've already done to know the _severity_ of the bug -- basically, a 
rough percentage of package users that would face the bug were they to 
emerge that version of the package right now, and the effect it would 
have on their system.  If anything, I tend to under-rank the severity.

An example of a "blocker" bug would be the one a few years ago where 
portage was screwing up glibc symlinks, pretty much killing the entire 
system for anyone that tried that (freshly unmasked IIRC) version!  (In 
that case it was a portage symlinking bug... that happened to occur at 
exactly the worst time possible, at almost exactly the same time a new 
glibc came out, triggering the bug in the worst possible way.) 

Similarly, the IIRC twice in nearing a decade on gentoo I've seen a bash 
bug (in ~arch, admittedly, where they're to expected from time to time 
and people running ~arch should be prepared to deal with it) that 
effectively killed the default system shell... for anyone happening to 
update to it on ~arch since that's where it was unmasked.

> As explained above, the security team has its own rules.

Basically what I was saying, they're handled separately (my words) and 
have their own rules (yours).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] robo-stable bugs

[Robin H. Johnson]

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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] robo-stable bugs

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

On Mon, 20 May 2013 18:00:49 +0000
"Robin H. Johnson" <robbat2@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] robo-stable bugs

[Michael Weber]

-----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 <xmw@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

[Jeroen Roovers]

On Mon, 20 May 2013 17:29:43 +0200
Tom Wijsman <TomWij@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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Wed, 22 May 2013 17:03:21 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Mon, 20 May 2013 17:29:43 +0200
> Tom Wijsman <TomWij@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: robo-stable bugs

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On Sun, 19 May 2013 15:40:27 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> >                 OS: Linux
> >             Status: CONFIRMED
> >           Severity: enhancement
> 
> Is a stabilisation an enhancement per se? If all stabilisations are
> enhancements, then why isn't Severity set to Normal instead? (What is
> an enhanced severity to begin with, Mozilla?)

Huh?  The severity of the bug is it's an enhancement.

Yes stabilizations are enhancements.  Always have been.

> Also, your script does not set the STABLEREQ keyword. People are having
> to hunt down your robo-stabilisation requests and add it themselves.
> You should just do it yourself or turn your script off.

Did you read the message?  The point is you're supposed to add that yourself.
It's not a STABLEREQ until you add arches.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: robo-stable bugs

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Tue, 21 May 2013 18:57:20 -0600
Ryan Hill <dirtyepic@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: robo-stable bugs

[Ulrich Mueller]

>>>>> On Wed, 22 May 2013, Tom Wijsman wrote:

> On Tue, 21 May 2013 18:57:20 -0600
> Ryan Hill <dirtyepic@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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Wed, 22 May 2013 11:07:26 +0200
Ulrich Mueller <ulm@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: robo-stable bugs

[Michael Palimaka]

On 22/05/2013 21:00, Tom Wijsman wrote:
> On Wed, 22 May 2013 11:07:26 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>
>>>> Is a stabilisation an enhancement per se? If all stabilisations
>>>> are enhancements, then why isn't Severity set to Normal instead?
>>>> (What is an enhanced severity to begin with, Mozilla?)
>>
>>> Why are they enhancements? Them having been this way is not a reason
>>> not to change the priority and severity fields to make more sense.
>>
>> Do you agree that a version bump, i.e. an ebuild entering ~arch is
>> an enhancement? Then why would it be different if the same ebuild gets
>> promoted from ~arch to arch?
>
> Is a version bump an enhancement per se? If all version bumps are
> enhancements, then why isn't Severity set to Normal instead? (What is
> an enhanced version bump to begin with, Mozilla?)
>
What does this statement even mean?

Re: [gentoo-dev] Re: robo-stable bugs

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

On Wed, 22 May 2013 21:07:45 +1000
Michael Palimaka <kensington@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: robo-stable bugs

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

On Wed, 22 May 2013 13:00:46 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Wed, 22 May 2013 11:07:26 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
> > > > Is a stabilisation an enhancement per se? If all stabilisations
> > > > are enhancements, then why isn't Severity set to Normal instead?
> > > > (What is an enhanced severity to begin with, Mozilla?)  
> >
> > > Why are they enhancements? Them having been this way is not a reason
> > > not to change the priority and severity fields to make more sense.
> > 
> > Do you agree that a version bump, i.e. an ebuild entering ~arch is
> > an enhancement? Then why would it be different if the same ebuild gets
> > promoted from ~arch to arch?
> 
> Is a version bump an enhancement per se?

Yes.  Nothing is broken.  There is no "bug" to fix.

> If all version bumps are
> enhancements, then why isn't Severity set to Normal instead? (What is
> an enhanced version bump to begin with, Mozilla?)

It's not an "enhanced" bug, the bug is a request for an improvement (aka
enhance_ment_). Severity is meant to give you a way of categorizing open bugs by
how important they are, as you may want to fix actual bugs before worrying
about adding features.  Maybe you don't use bugzilla like that but some
people do and lumping these bugs in with the "normal" ones prevents them from
doing so.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: robo-stable bugs

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On Thu, 23 May 2013 23:20:00 -0600
Ryan Hill <dirtyepic@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: robo-stable bugs

[Michael Palimaka]

On 22/05/2013 18:58, Tom Wijsman wrote:
> On Tue, 21 May 2013 18:57:20 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
>
>> Huh?  The severity of the bug is it's an enhancement.
>>
>> Yes stabilizations are enhancements.  Always have been.
>
> Why are they enhancements? Them having been this way is not a reason
> not to change the priority and severity fields to make more sense.
A newer version of a package is usually considered to be better in some 
way, hence it is an enhancement.

>
>>> Also, your script does not set the STABLEREQ keyword. People are
>>> having to hunt down your robo-stabilisation requests and add it
>>> themselves. You should just do it yourself or turn your script off.
>>
>> Did you read the message?  The point is you're supposed to add that
>> yourself. It's not a STABLEREQ until you add arches.
>
> Yet the base system lead went and apply it to any stabilization bug; as
> both him and Jer (the bug wrangling lead) do it this way, I'll be doing
> it as well. Let's not be inconsistent with our leads unless there is
> a wide decision to do so; I expect none will come, unless you really
> think this should become Council material.
>
According to the bug-wrangler's own docs[1]: "A stabilisation request 
should be handled by the package's maintainer, so you should not CC arch 
teams in your role as bug wrangler, nor set the STABLEREQ keyword in the 
Keywords field.". There should at least be some consistency there before 
telling people what to do.

As for base system, I don't really see what bearing their actions has to 
do with anything to on bugzilla. (And let's not forget that the current 
lead has a history of doing whatever he wants, so I don't think the 
actions that come out of that are a good example to follow).

[1]: http://www.gentoo.org/proj/en/qa/bug-wranglers/

Re: [gentoo-dev] Re: robo-stable bugs

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

On Wed, 22 May 2013 19:18:41 +1000
Michael Palimaka <kensington@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: robo-stable bugs

[Jeroen Roovers]

On Wed, 22 May 2013 19:18:41 +1000
Michael Palimaka <kensington@gentoo.org> wrote:

> A newer version of a package is usually considered to be better in
> some way, hence it is an enhancement.

Unless it's a Blocker, of course. :)

> According to the bug-wrangler's own docs[1]: "A stabilisation request 
> should be handled by the package's maintainer, so you should not CC
> arch teams in your role as bug wrangler, nor set the STABLEREQ
> keyword in the Keywords field.". There should at least be some
> consistency there before telling people what to do.

I am trying to find consensus based on reasonable argument here.

> [1]: http://www.gentoo.org/proj/en/qa/bug-wranglers/

Documentation/policy should change after discussion. I set up the b-w
project to get something of a standard going, not to "[tell] people
what to do". I have been adding STABLEREQ recently because it's
turning out to be more practical (mainly because developers keep
forgetting to add it, despite the helpful suggestion from the
robo-script).

I will change the default in the b-w doc if I find there is reasonable
consensus on the matter.


    jer

[gentoo-dev] Re: robo-stable bugs

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Wed, 22 May 2013 10:58:26 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Tue, 21 May 2013 18:57:20 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:

> > > Also, your script does not set the STABLEREQ keyword. People are
> > > having to hunt down your robo-stabilisation requests and add it
> > > themselves. You should just do it yourself or turn your script off.
> > 
> > Did you read the message?  The point is you're supposed to add that
> > yourself. It's not a STABLEREQ until you add arches.
> 
> Yet the base system lead went and apply it to any stabilization bug; as
> both him and Jer (the bug wrangling lead) do it this way, I'll be doing
> it as well. Let's not be inconsistent with our leads unless there is
> a wide decision to do so

Okay, so what are you using the STABLEREQ keyword for that you want to set it
when the bug is filed but before archs are added?  If you want to see only
stabilization bugs you can search in the Keywording and Stabilization
component.  Can you suggest another way to search for stabilization bugs that
don't yet have archs CC'd (which is something I find rather useful)?


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: robo-stable bugs

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

On Thu, 23 May 2013 23:40:42 -0600
Ryan Hill <dirtyepic@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: robo-stable bugs

[Jeroen Roovers]

On Thu, 23 May 2013 23:40:42 -0600
Ryan Hill <dirtyepic@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

[Jeroen Roovers]

On Tue, 21 May 2013 18:57:20 -0600
Ryan Hill <dirtyepic@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