On Thu, 2020-06-18 at 21:34 +0200, Christian Boltz wrote:
Hello,
Am Donnerstag, 18. Juni 2020, 02:04:19 CEST schrieb Simon Lees:
On 6/18/20 4:42 AM, Christian Boltz wrote:
Am Mittwoch, 17. Juni 2020, 11:13:39 CEST schrieb Dirk Müller:
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
-> less _than_ 10% _of the_ packages failing
Speaking about that - 10% would mean to allow about 1300 failing packages. Maybe I'm too optimistic, but - isn't that a bit ;-) too much? A quick check shows: - x86_64 currently has 279 failed + 62 unresolvable = 341, with 13000 successful builds that makes 2.6% - aarch64 has similar numbers, but is currently rebuilding - someone will have to re-check tomorrow
The builds finished in the meantime: 311 failed + 77 unresolvable = 388. Compared to 12842 succeeded packages, that's 3.0% failing packages.
- armv7l has 360 failed + 137 unresolvable = 497 - compared to 12631 successful builds, that makes 3.9% (I'll ignore the 5 packages in the rebuild queue)
Therefore I'd say allowing 5% build failures would be enough.
I guess it might depend when you check, if you check the day after a new python or gcc lands it will probably be a larger percentage.
Yes, obviously these numbers can vary. I have to admit that I don't check regularly and therefore don't know the amount of breakage we typically see after a gcc or python update (hopefully not too much - staging projects should catch many of the problems early enough).
That said - the full proposed rule (without my proposed modifications) is:
The architecture team is at all times focused on keeping every package re-buildable from sources. There should be less of 10% packages failing to build from source at any point in time.
Note the "should" - so if a new gcc or python indeed breaks lots of packages, I'm sure we won't instantly "downgrade" a Tier 1 distro because it _temporarily_ has more than 5% failing packges.
OTOH, if the rule says 10%, that would allow much more _permanent_ failures, which is a bad idea from a quality POV. ("Hey, luckily those broken python packages are only 9.9% of the distro. No need to fix them!" ;-)
Well it's not about not fixing them, it's the state where we should stop considering architecture as a Tier 1 arch, because obviously we can't keep the quality on sufficient level.
I clearly prefer the 5% rule (it's a good motivation!), even if it gets temporarily violated in rare cases.
I also agree with Michal that the core packages will need a more strict rule. If the kernel or bash fail to build, we can stop any discussion about percentages ;-)
I guess if you were also to think in terms of an architecture like s390x then the total number of packages that it makes sense to support are likely much smaller which would have the potential to push up the percentage failed by a significant amount.
Sounds like a good motivation to fix those failing packages ;-)
Seriously: So far, I haven't seen any indication [1] that s390x will be proposed to become a Tier 1 distro - so there's no need to have a more permissive limit "just in case".
But: Let's talk about this when we discuss to make s390x a Tier 1 distro ;-)
Regards,
Christian Boltz
[1] "0 tests passing" doesn't sound too promising ;-) --
ist cyber-top(1) nicht das Tool um anzuzeugen welcher Prozess gerade wie viel rum-cybert? A la top(1), iotop(8) etc. .. und isotopp(8) nicht zu vergessen.. [Evgeni Golov und Christian Bricart zu https://plus.google.com/+KristianKöhntopp/posts/VV5tiv8yFF4]