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