| 1 |
On 2017-12-14 20:45, William Hubbs wrote: |
| 2 |
> I tend to like this better. Let's try to move away from filing stable |
| 3 |
> requests for new versions of packages once an old version is stable and |
| 4 |
> have a way to block newer versions from going stable. Maybe buildbot |
| 5 |
> could check to see if there is a bug open against the version it is |
| 6 |
> looking at, then check the keywords or severity of that bug and use one |
| 7 |
> or the other of those to decide whether or not to skip stabilizing that version |
| 8 |
> of the package. |
| 9 |
|
| 10 |
How would you identify such a bug? Someone reports a bug. He/she is |
| 11 |
using app-misc/foo-1.2-r2 at the moment. It is often not clear if the |
| 12 |
bug affects only =app-misc/foo-1.2-r2, >=, ... What's about foo-2.0? |
| 13 |
Maybe foo-1.1 is also affected but wasn't (yet) tested... |
| 14 |
|
| 15 |
|
| 16 |
> In other words, the first stabilization for a package on an architecture |
| 17 |
> should be done the way we currently do them, by filing a stable request |
| 18 |
> then using the current stabilization process. |
| 19 |
|
| 20 |
I am not sure if something like this should be a general rule. But like |
| 21 |
said, maintainer could either opt-in or opt-out from auto-stabilization. |
| 22 |
So if you think your new package is somehow special... |
| 23 |
|
| 24 |
|
| 25 |
-- |
| 26 |
Regards, |
| 27 |
Thomas Deutschmann / Gentoo Linux Developer |
| 28 |
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |
Archives