| 1 |
On Wed, Dec 13, 2017 at 09:58:05PM +0100, Thomas Deutschmann wrote: |
| 2 |
|
| 3 |
*snip* |
| 4 |
|
| 5 |
> b) Because not all devs care about stable Gentoo, I would recommend |
| 6 |
> auto-stabilization: I.e. if a package is in the repository for x days |
| 7 |
> build bot would try to build the package and mark the package stable if |
| 8 |
> everything passes. If for some reason maintainer want to block a |
| 9 |
> specific version they could create a bug or set a flag in an already |
| 10 |
> existing bug which will cause build bot to ignore this version. |
| 11 |
|
| 12 |
I tend to like this better. Let's try to move away from filing stable |
| 13 |
requests for new versions of packages once an old version is stable and |
| 14 |
have a way to block newer versions from going stable. Maybe buildbot |
| 15 |
could check to see if there is a bug open against the version it is |
| 16 |
looking at, then check the keywords or severity of that bug and use one |
| 17 |
or the other of those to decide whether or not to skip stabilizing that version |
| 18 |
of the package. |
| 19 |
|
| 20 |
I think something else we should add to this is that buildbot should do |
| 21 |
nothing if there isn't already a stable version of the package on the |
| 22 |
architecture it is testing. |
| 23 |
|
| 24 |
In other words, the first stabilization for a package on an architecture |
| 25 |
should be done the way we currently do them, by filing a stable request |
| 26 |
then using the current stabilization process. |
| 27 |
|
| 28 |
William |
Archives