On 07/12/2017 07:26 AM, Kristian Fiskerstrand wrote:> That presumes that the maintainer is the one calling for the > stabilization, and it is not an automated procedure simply due to 30 > days in ~arch. In this particular case, look for the number of bug > reports filed in Gentoo for the issue.
All of the past automated stabilisation request initiatives did look for open bugs against a package before filing any request. > > But the main risk is certainly not built testing, it is breaking > operational live stable systems. I'm not sure exactly what you mean by this. Build testing is a process and not a risk. When ebuilds are moved to stable, there's risk of breakage at both build time and runtime. Most runtime issues will either be known by the maintainer (who can then block the stabilisation) or smoked out during the usual ~arch waiting period. Build time issues are more tricky. One of the reasons we have arch testers is to ensure that something that built fine in ~arch will still build fine on an otherwise stable system. I've encountered a number of ebuilds marked stable that failed to build on an all-stable system but built fine on an all-testing system. I've never encountered a single ebuild that failed to run correctly on an all-stable system but ran fine on an all-testing system. I don't think it's practical to demand detailed runtime testing by an arch tester for every stabilisation request (which we know doesn't happen in practice anyway). There's also many packages where it may be prudent to do more than just build testing. I think the answer lies somewhere in the middle. We need to recognise that we have very limited arch testing resources and focus them where it will have the most impact. We have a "runtime testing required" field on stable bugs now - let's use it, and let's be smart about it. Looking at the current open bugs, I see some good examples where runtime testing was requested (eg. sys-devel/gcc-config) and some examples where I really question what value we get from an arch tester's time (eg. app-text/htmldoc). > Nowhere was it claimed that the arc > testers are responsible for it, but it certainly doesn't coincide, at > any point, with "The main risk of breakage of a package moving from > testing to stable is always at build time anyway." In a previous post you stated: > currently gnupg 2.1.21 scdaemon bug will > happily sign a third party public keyblock's UID using signature subkey > on smartcard, which results in useless signature that doesn't have any > effect, but the application builds fine. > > This means gnupg 2.1.21 is not a candidate for stabilization, but it certainly builds fine. If it's not a stable candidate then why do you use this as an example against build testing-based stabilisations? If there are known issues it should never reach the arch teams in the first place.
