| 1 |
On 2017-12-14 13:58, Kent Fredric wrote: |
| 2 |
> On Wed, 13 Dec 2017 21:58:05 +0100 |
| 3 |
> Slightly modified suggestion: |
| 4 |
> |
| 5 |
> Add a flag called "autostabilize" with [unset], [y], [n] |
| 6 |
> |
| 7 |
> Default is 'unset', and if found unset after a given time, it flips to |
| 8 |
> y and the stable bot gets queued up. |
| 9 |
> |
| 10 |
> If its set to 'n', then stable bot never does anything. |
| 11 |
> |
| 12 |
> This way maintainers who want to rush the stablebot on things they |
| 13 |
> consider "safe" can get ahead of the queue. |
| 14 |
|
| 15 |
Well, we kind of have that already with “Runtime testing required” (RTR). |
| 16 |
|
| 17 |
RTR=no stablereqs are good candidates for automation. |
| 18 |
|
| 19 |
If everything has been properly handled in the ebuild, then an emerge |
| 20 |
should succeed. And, RTR being set to “No” indicates that there aren’t any |
| 21 |
tests to perform other than those defined and handled within the ebuild. |
| 22 |
|
| 23 |
Restricting the set to RTR=no would eliminate special cases needing to |
| 24 |
be taken into consideration. |
| 25 |
|
| 26 |
Of course, RTR being unset or set to yes should be skipped. |
| 27 |
|
| 28 |
We could initially start with stablebot only adding a comment to a bug |
| 29 |
that it thinks it’s safe to stabilize the subject. This would give us |
| 30 |
some time to gain confidence in it and/or weed out the bugs. |
Archives