On Thu, Dec 14, 2017 at 7:07 AM, Aaron W. Swenson <titanof...@gentoo.org> wrote: > On 2017-12-14 13:58, Kent Fredric wrote: >> On Wed, 13 Dec 2017 21:58:05 +0100 >> Slightly modified suggestion: >> >> Add a flag called "autostabilize" with [unset], [y], [n] >> >> Default is 'unset', and if found unset after a given time, it flips to >> y and the stable bot gets queued up. >> >> If its set to 'n', then stable bot never does anything. >> >> This way maintainers who want to rush the stablebot on things they >> consider "safe" can get ahead of the queue. > > Well, we kind of have that already with “Runtime testing required” (RTR). > > RTR=no stablereqs are good candidates for automation. > > If everything has been properly handled in the ebuild, then an emerge > should succeed. And, RTR being set to “No” indicates that there aren’t any > tests to perform other than those defined and handled within the ebuild.
I'm not sure runtime testing is the only use case for preventing auto-stabilization. The example of KDE/Gnome was brought up where large number of packages need to be stabilized at the same time. I'm not sure this is actually a factor that should prevent auto-stabilization, since these packages should have the correct dependencies and the stabilization system would definitely need to be dependency-aware (which would lead to them being stabilized as a group automatically). If these require runtime testing then they fall into the existing use case. Does anybody actually have a reason to prevent stabilization other than for runtime testing, assuming that stabilization is done in a manner where all dependencies are satisfied at all times? Maybe runtime testing really ought to be the only reason to prevent auto stabilization... -- Rich
