Re: [gentoo-dev] robo-stable bugs

On 5/21/13 6:38 AM, Thomas Sachau wrote:
> And if a maintainer is not responding within 30 days, you can ping him
> or, without a response, try to get a different maintainer. Just assuming
> that a stable request is ok without a maintainer response is really not
> a good idea.

Thomas, this effort is going on for over a year now (and has been
discussed on gentoo-dev). If it's only now you've noticed, maybe the sky
isn't falling after all.

Note the criteria for the bugs to be filed:

1. No open bugs for the package.
2. No bugs (including closed) for that particular version of the package
(so for example closing the stabilization bug will prevent it from being
opened again; it also takes into account bugs closed with e.g. NEEDINFO,
which can be real issues).
3. At least 30 days in tree.
4. No repoman errors when trying to stabilize it (so all deps already
stable).

Also, arch teams are responsible for at least shallow (compile) testing
of the package, and ideally smoke testing on run and possibly testing
with various USE flag combinations and reverse dependencies testing (the
latter is a regular part of my stabilization workflow, and the script
for that is part of the same suite that files bugs).

Note that there is a tradeoff here: I really started the stabilizations
after I've noticed how many bugs are fixed in ~arch that still affect
stable, but the fixing version didn't get stabilized. This is the
downside of an opt-in approach, since inactive maintainers are not going
to opt-in.

Finally, everyone from metadata.xml is CC-ed. There is no "trying a
different maintainer" - all of them are there since day one.

Please let me know if you still have concerns - ideally back them with
data and actual cases showing problems (or scenarios that can reasonably
be likely) instead of just saying it _might_ lead to breakages. Anything
_might_ lead to breakages, including taking no action here and allowing
bugs to be not fixed for stable. :)

Paweł