On Tue, 21 May 2013 15:32:25 +0200
Thomas Sachau <to...@gentoo.org> wrote:
> Automagic stabilization is a bad idea.
I agree. "Maintainer timeout" is not a valid reason to go
ahead with stabilisation. If you really want to push forward, you
should be required to do more research as bug reporter.
> And just because a maintainer can opt-out per bug, it does not change
> the automagic behaviour nor does it make this thing any better. In
> this case, there are enough possible cases, where a maintainer does
> miss the bug, so again a package may become stable, also it should
> never have been a stable candidate. So again:
If a specific ebuild should never go stable but is, by default, a
stable target, then you can do several things:
1) Remove it from the tree
If it should never go stable, then ask yourself why it's in the tree.
2) Put it in package.mask
Add some reasons, like bug reports that explain what needs to be done
to once again make it a stabilisation target.
3) File a bug report detailing while it shouldn't go stable
Ebuilds with open bugs should never go stable. This is detailed in the
(correct answers to the) quizzes and so on, IIRC, and in [1]. This
makes robo-stable requests difficult, though, since the bug report in
question could be summarised as
"<some-cat/pkg> with <stable/target> has issue foo"
and then phajdan.jr's robo-script should be able to recognise it.[2]
jer
[1] http://devmanual.gentoo.org/keywording/index.html
[2] Or wait, some human interaction is again called for to fix the
bureaucratic mess the script created! Since we still cannot
pinpoint a specific cat/pkg/ver-rev in a bug report, it's down to
scraping and regexen again.
