| 1 |
On 2017-12-13 18:51, William Hubbs wrote: |
| 2 |
> In theory, this is correct. However, when maintainers don't stabilize |
| 3 |
> packages and no one else does either, our stable tree suffers. |
| 4 |
|
| 5 |
I agree but we have to pay attention that we don't stabilize packages at |
| 6 |
all costs because otherwise they would never go stable. |
| 7 |
|
| 8 |
If this is the problem then we should discuss stabilization at all. What |
| 9 |
do people expect from something marked stable vs. reality. ;) |
| 10 |
|
| 11 |
And in this case I would prefer a system like Debian SID -> Testing |
| 12 |
supported by build bots. I can think of 2 variants: |
| 13 |
|
| 14 |
a) Once maintainer files a stabilization request, a build bot will pick |
| 15 |
up the bug and try building the package in a chroot per architecture. If |
| 16 |
everything passes build bot will mark the version stable for the tested |
| 17 |
architecture. |
| 18 |
|
| 19 |
A flag or a blacklist could prevent build bot stabilization. |
| 20 |
|
| 21 |
|
| 22 |
b) Because not all devs care about stable Gentoo, I would recommend |
| 23 |
auto-stabilization: I.e. if a package is in the repository for x days |
| 24 |
build bot would try to build the package and mark the package stable if |
| 25 |
everything passes. If for some reason maintainer want to block a |
| 26 |
specific version they could create a bug or set a flag in an already |
| 27 |
existing bug which will cause build bot to ignore this version. |
| 28 |
|
| 29 |
|
| 30 |
-- |
| 31 |
Regards, |
| 32 |
Thomas Deutschmann / Gentoo Linux Developer |
| 33 |
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |
Archives