Re: [gentoo-dev] robo-stable bugs

[Michael Mol]

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