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