Hi all,
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
This is a draft aiming to define what a Premium Tier openSUSE Distribution architecture is. Currently this is mostly x86_64 as it stands today out of historic reasons, and rather than letting historic reasons define the future, I'd like to make it a bit more transparent on why that is and what quality standards an openSUSE distribution has to offer for other architectures to be considered also a main / premium Tier openSUSE Distribution.
Please be aware that this does not silently introduce aarch64 as a premium tier, however it is aimed to define the rules that any architecture port including aarch64 would have to meet in order to be considered a premium tier. So once we agree on the terms and scope, AArch64 would be requested to be evaluated against this.
For the interest of tracking, please refrain from editing the main page, and use either the mailing list discussion here or the Talk page for comments/questions/considerations/feedback.
Thanks!
Dirk
On Wed, Jun 17, 2020 at 11:13:39AM +0200, Dirk Müller wrote:
Please be aware that this does not silently introduce aarch64 as a premium tier, however it is aimed to define the rules that any architecture port including aarch64 would have to meet in order to be considered a premium tier. So once we agree on the terms and scope, AArch64 would be requested to be evaluated against this.
Can't help thinking about the opposite: the question if i586 still satisfies the criteria and if it should be still considered premium tier architecture.
AFAICS we do not run i586 tests in openQA and I don't think majority of package maintainers does actually care about i586 beyond reactively responding to OBS build failures or reported bugs. I would even dare to say more developers and maintainers (both upstream and openSUSE) in fact care about aarch64 than about i586.
Michal
On Wed, 2020-06-17 at 14:38 +0200, Michal Kubecek wrote:
On Wed, Jun 17, 2020 at 11:13:39AM +0200, Dirk Müller wrote:
Please be aware that this does not silently introduce aarch64 as a premium tier, however it is aimed to define the rules that any architecture port including aarch64 would have to meet in order to be considered a premium tier. So once we agree on the terms and scope, AArch64 would be requested to be evaluated against this.
Can't help thinking about the opposite: the question if i586 still satisfies the criteria and if it should be still considered premium tier architecture.
AFAICS we do not run i586 tests in openQA and I don't think majority of package maintainers does actually care about i586 beyond reactively responding to OBS build failures or reported bugs. I would even dare to say more developers and maintainers (both upstream and openSUSE) in fact care about aarch64 than about i586.
We do run openQA tests (allbeit limited to a rather low set); and i586 is still very mandatory for package builds, as otherwise there are no -32bit packages, no steam, no wine
Of course, there are a few packages where upstream clearly states they are no longer caring for i586 and no longer build for this platform - but that is handled via ExcludeArch tags in spec files.
Cheers, Dominique
On Wed, Jun 17, 2020 at 02:49:11PM +0200, Dominique Leuenberger / DimStar wrote:
On Wed, 2020-06-17 at 14:38 +0200, Michal Kubecek wrote:
On Wed, Jun 17, 2020 at 11:13:39AM +0200, Dirk Müller wrote:
Please be aware that this does not silently introduce aarch64 as a premium tier, however it is aimed to define the rules that any architecture port including aarch64 would have to meet in order to be considered a premium tier. So once we agree on the terms and scope, AArch64 would be requested to be evaluated against this.
Can't help thinking about the opposite: the question if i586 still satisfies the criteria and if it should be still considered premium tier architecture.
AFAICS we do not run i586 tests in openQA and I don't think majority of package maintainers does actually care about i586 beyond reactively responding to OBS build failures or reported bugs. I would even dare to say more developers and maintainers (both upstream and openSUSE) in fact care about aarch64 than about i586.
We do run openQA tests (allbeit limited to a rather low set); and i586 is still very mandatory for package builds, as otherwise there are no -32bit packages, no steam, no wine
Yes, -32bit compatibility packages are (unfortunately) still important. But there is IMHO a big difference between considering these (and their build dependencies) essential and considering the whole architecture (i.e. distribution which can be actually installed, booted and used) premium tier.
I'm not saying we should drop i586 completely (even if I wouldn't mind) but if we are trying to define clear set of criteria for promoting new architectures from ports to the "premium tier" status, it would be only fair to check if existing premium tier architectures (like i586) still meet these criteria.
Michal
Hello,
Am Mittwoch, 17. Juni 2020, 11:13:39 CEST schrieb Dirk Müller:
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
For the interest of tracking, please refrain from editing the main page, and use either the mailing list discussion here or the Talk page for comments/questions/considerations/feedback.
The proposed policy makes sense. However, I found some typos - and came up with a question while listing the typos ;-)
The Tumbleweed version of the distribution is regularly publishing new snapshots (at least one a month)
-> one _per_ month or on_c_e a month
There should be less of 10% packages failing to build from source at any point in time.
-> 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 - 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.
Back to the typos:
However common practices focus more on the "core" package set (on x86_64 this is defined by the DVD media set) than on leave packages.
-> lea_f_ packages
Regards,
Christian Boltz
On Wed, Jun 17, 2020 at 09:12:10PM +0200, Christian Boltz wrote:
-> 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
- 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.
IMHO the percentage should not be the only criterion and we should take into account the fact that there are big differences between packages. If something like kernel, glibc, openssl, bash or systemd fails to build, it's a problem that has to be resolved ASAP; you cannot just wave your hand and say "it's OK, we are at 4.5%". So IMHO there should be different limits for e.g Ring 0, Ring 1 and other packages. Maybe we should even define set of "essential" packages which must build on all premium tier architectures.
Michal
On 6/17/20 10:46 PM, Michal Kubecek wrote:
IMHO the percentage should not be the only criterion and we should take into account the fact that there are big differences between packages. If something like kernel, glibc, openssl, bash or systemd fails to build, it's a problem that has to be resolved ASAP; you cannot just wave your hand and say "it's OK, we are at 4.5%". So IMHO there should be different limits for e.g Ring 0, Ring 1 and other packages. Maybe we should even define set of "essential" packages which must build on all premium tier architectures.
There can also be some packages which are x86-only by design such as dosemu.
Adrian
On Jun 17 2020, John Paul Adrian Glaubitz wrote:
There can also be some packages which are x86-only by design such as dosemu.
That is already handled by Exlu{de,sive}Arch.
Andreas.
On 6/18/20 9:08 AM, Andreas Schwab wrote:
On Jun 17 2020, John Paul Adrian Glaubitz wrote:
There can also be some packages which are x86-only by design such as dosemu.
That is already handled by Exlu{de,sive}Arch.
Provided that the maintainer uses the field correctly, yes :).
Adrian
On 6/18/20 4:42 AM, Christian Boltz wrote:
Hello,
Am Mittwoch, 17. Juni 2020, 11:13:39 CEST schrieb Dirk Müller:
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
For the interest of tracking, please refrain from editing the main page, and use either the mailing list discussion here or the Talk page for comments/questions/considerations/feedback.
-> 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
- 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. 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.
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!" ;-)
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 ;-)
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%C3%B6hntopp/posts/VV5tiv8yFF4]
Hi Christian,
Am Do., 18. Juni 2020 um 21:34 Uhr schrieb Christian Boltz opensuse@cboltz.de:
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!" ;-)
I clearly prefer the 5% rule (it's a good motivation!), even if it gets temporarily violated in rare cases.
Thanks, that's convincing. I've changed the wording to:
* The architecture team is at all times focused on keeping every package re-buildable from sources. There should be less than 5% of the packages failing to build from source at any point in time, and core packages for the distribution (What is defined as Ring-0 today) should to be always successfully re-buildable.
On 6/25/2020 14:00, Dirk Müller wrote:
Thanks, that's convincing. I've changed the wording to:
- The architecture team is at all times focused on keeping every
package re-buildable from sources. There should be less than 5% of the packages failing to build from source at any point in time, and core packages for the distribution (What is defined as Ring-0 today) should to be always successfully re-buildable.
May I suggest the wording "should always be successfully re-buildable".
-- Jason Craig
Am Fr., 26. Juni 2020 um 17:04 Uhr schrieb Jason Craig os-dev@jacraig.com:
May I suggest the wording "should always be successfully re-buildable".
Thanks - yes that makes sense. I've updated the wording.
Greetings, Dirk
On 6/19/20 5:04 AM, Christian Boltz wrote:
Hello,
Am Donnerstag, 18. Juni 2020, 02:04:19 CEST schrieb Simon Lees:
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 ;-)
I think the point of this policy is that it should be flexible enough that it doesn't need to be modified again in the future should someone want to work on making s390x or RISC-V a tier 1 distro the rules will already be in place correctly.
Hi Christian,
Am Mi., 17. Juni 2020 um 21:12 Uhr schrieb Christian Boltz opensuse@cboltz.de:
sorry for the slow reply, other real life issues took over.
The proposed policy makes sense. However, I found some typos - and came up with a question while listing the typos ;-)
I fixed all the typos. thanks a lot for your help!
-> 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?
well, the important part is 'at any point in time'
- 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
Yes, it usually is much lower, but there are days where things are tougher.
That being said, I am okay with lowering the threshold to 5% of thats what make us agree to the policy.
Greetings, Dirk
Am 17.06.20 um 11:13 schrieb Dirk Müller:
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Just a brief remark about this bullet point:
The distribution maintainers are filing bugreports on https://bugzilla.opensuse.org/ for package maintainers if there are issues identified in the architecture port. The package maintainers commit to handle Tier 1 platforms with care. The package maintainers commit to handle regressions quickly and in general accept bugreports for that platform and work on a resolution.
When I was working on the update to LLVM 10, I had to fight a nasty misoptimization issue on s390x. There was a garbage pointer, and I had to follow its tracks through 3 or 4 functions. Most of this in assembly. (Partly because it was a segfault, partly because gdb would take forever when loading debug info for libLLVM.) Unsurprisingly I'm not so familiar with s390x assembly, though I appreciated the opportunity to learn about it. Also unsurprisingly, I didn't have a suitable machine sitting around and had to debug through QEMU. That did in fact work, though obviously not always smoothly. It was somewhat interesting, but it took me a lot of time to eventually find the bug. [1]
Luckily issues like that are rare, but in general it would be good to have people familiar with the architecture assisting.
Maybe we can move that last sentence somewhat towards collaboration between package and distribution maintainers, with the weight maybe depending on the importance of the package/distribution? For important packages, distribution maintainers should be willing to invest some more time, and vice versa for important distributions, package maintainers should be willing to invest some more time. Does that make sense?
Best regards, Aaron
[1] For the curious: https://bugs.llvm.org/show_bug.cgi?id=45272.
Hi Aaron,
Am Do., 18. Juni 2020 um 01:53 Uhr schrieb Aaron Puchert aaronpuchert@alice-dsl.net:
Luckily issues like that are rare, but in general it would be good to have people familiar with the architecture assisting.
Yes, I think this is a great point, and it was missing in the policy. I've added this wording:
* There is an active set of regular contributors caring about the distribution build and that is reachable via a common mailing list for questions from packagers in case of architecture specific defects ('Architecture Team').
That's good for you?
Thanks, Dirk
Am 25.06.20 um 21:54 schrieb Dirk Müller:
Luckily issues like that are rare, but in general it would be good to have people familiar with the architecture assisting.
Yes, I think this is a great point, and it was missing in the policy. I've added this wording:
- There is an active set of regular contributors caring about the
distribution build and that is reachable via a common mailing list for questions from packagers in case of architecture specific defects ('Architecture Team').
That's good for you?
Yes, the mailing list is a good idea.
Best regards, Aaron
Dear openSUSE citizens,
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Thanks to everyone who already provided valuable feedback and input. I've addressed all the comments I received so far.
I would like to close the review period. If I don't hear from you by July 1st, I'll suggest to remove the 'DRAFT' label and consider it accepted.
Thanks, Dirk
On Wed 2020-06-17, Dirk Müller wrote:
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Thank you for kicking this off, Dirk!
This is a good initiative, and important to clarify and be open and transparent, and I like the document you prepared.
For the interest of tracking, please refrain from editing the main page, and use either the mailing list discussion here or the Talk page for comments/questions/considerations/feedback.
A small change I'd suggest is to avoid the use of the phrase "premium tier".
And make the "As of 2020" more specific, unless definitely nobody plans to propose any changes in the next 26 weeks. ;-)
From a messaging perspective, I recommend not to call the other
ports "unofficial ports". They are officially part of openSUSE, I'd argue, just not Tier 1. (It's a bit like calling an assistant doctor and unofficial doctor. ;-)
I think it would be helpful to describe the distribution of responsibilities between individual package maintainers and the architecture teams. That is a note or two in the specific items of the policy, so more an overarching sentence along the lines of the following (which very raw and rought strawman only) as a preamble:
Individual package maintainers will strive to package things such that they build on all platforms they can reasonable support. The general working of an architecture (booting, kernel, toolchain,...) and architecture-specific build failures and bugs primarily resides with the architecture maintainers.
Hope this makes sense?
And, again, thank you very much for driving this. It's good to have such things formulated and out there for everyone to see (and, if there is interest, work towards)!
Gerald
On Fri, Jul 3, 2020 at 11:59 AM Gerald Pfeifer gp@suse.com wrote:
On Wed 2020-06-17, Dirk Müller wrote:
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Thank you for kicking this off, Dirk!
This is a good initiative, and important to clarify and be open and transparent, and I like the document you prepared.
For the interest of tracking, please refrain from editing the main page, and use either the mailing list discussion here or the Talk page for comments/questions/considerations/feedback.
A small change I'd suggest is to avoid the use of the phrase "premium tier".
And make the "As of 2020" more specific, unless definitely nobody plans to propose any changes in the next 26 weeks. ;-)
From a messaging perspective, I recommend not to call the other ports "unofficial ports". They are officially part of openSUSE, I'd argue, just not Tier 1. (It's a bit like calling an assistant doctor and unofficial doctor. ;-)
I think it would be helpful to describe the distribution of responsibilities between individual package maintainers and the architecture teams. That is a note or two in the specific items of the policy, so more an overarching sentence along the lines of the following (which very raw and rought strawman only) as a preamble:
Individual package maintainers will strive to package things such that they build on all platforms they can reasonable support. The general working of an architecture (booting, kernel, toolchain,...) and architecture-specific build failures and bugs primarily resides with the architecture maintainers.
Hope this makes sense?
I think we should just straight up drop this idea of tiering. Is there a good reason we can't just go with primary and secondary architectures as other distros (Debian, Fedora, etc.) do?
We can use "main" and "alternative" if "primary" and "secondary" make people uncomfortable. But tiering is a term I don't want to see invoked here, as it involves quality separation, which is not what this should be about.
-- 真実はいつも一つ！/ Always, there's only one truth!
Hi Neal,
Thanks for the feedback - you're touching the point I also feel least comfortable with. so lets dive right into it. Funny that you bring up Fedora as a counter example. from the first line of: https://fedoraproject.org/wiki/Architectures#Primary_Architectures
"There are *two* *tiers* of architectures with Fedora support"
On the other hand, Debian seems to call it 'supported architecture' and 'ports'. I don't like the term 'supported' as that is a trigger word in other contexts..
I think we should just straight up drop this idea of tiering. Is there a good reason we can't just go with primary and secondary architectures as other distros (Debian, Fedora, etc.) do?
I used the term Tier because I was looking for one word that includes 'main' and 'ports', which are the two levels/architecture groupings I am aiming for.
I agree that 'Tier 1/premium' is not a good wording. I didn't find a better one. Primary and secondary is maybe also not inclusive-language enough.
For me the most natural way would be to describe them as 'main' and 'ports', and that's what we used most commonly everywhere so far. I just need a word for 'both'. Maybe it's just 'Architecture Policy'.
So I rename it to 'openSUSE Distribution Architecture Policy' ?
That seems like a great solution. Agree?
Thanks, Dirk
On Fri, Jul 3, 2020 at 12:29 PM Dirk Müller dirk@dmllr.de wrote:
Hi Neal,
Thanks for the feedback - you're touching the point I also feel least comfortable with. so lets dive right into it. Funny that you bring up Fedora as a counter example. from the first line of: https://fedoraproject.org/wiki/Architectures#Primary_Architectures
"There are *two* *tiers* of architectures with Fedora support"
On the other hand, Debian seems to call it 'supported architecture' and 'ports'. I don't like the term 'supported' as that is a trigger word in other contexts..
I think we should just straight up drop this idea of tiering. Is there a good reason we can't just go with primary and secondary architectures as other distros (Debian, Fedora, etc.) do?
I used the term Tier because I was looking for one word that includes 'main' and 'ports', which are the two levels/architecture groupings I am aiming for.
I agree that 'Tier 1/premium' is not a good wording. I didn't find a better one. Primary and secondary is maybe also not inclusive-language enough.
For me the most natural way would be to describe them as 'main' and 'ports', and that's what we used most commonly everywhere so far. I just need a word for 'both'. Maybe it's just 'Architecture Policy'.
So I rename it to 'openSUSE Distribution Architecture Policy' ?
That seems like a great solution. Agree?
Calling it that makes sense. Perhaps we can go with "main" and "alternate" for architectures, since that makes more sense from the perspective you're talking about.
On Fri, Jul 3, 2020 at 12:31 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jul 3, 2020 at 12:29 PM Dirk Müller dirk@dmllr.de wrote:
Hi Neal,
Thanks for the feedback - you're touching the point I also feel least comfortable with. so lets dive right into it. Funny that you bring up Fedora as a counter example. from the first line of: https://fedoraproject.org/wiki/Architectures#Primary_Architectures
"There are *two* *tiers* of architectures with Fedora support"
On the other hand, Debian seems to call it 'supported architecture' and 'ports'. I don't like the term 'supported' as that is a trigger word in other contexts..
I think we should just straight up drop this idea of tiering. Is there a good reason we can't just go with primary and secondary architectures as other distros (Debian, Fedora, etc.) do?
I used the term Tier because I was looking for one word that includes 'main' and 'ports', which are the two levels/architecture groupings I am aiming for.
I agree that 'Tier 1/premium' is not a good wording. I didn't find a better one. Primary and secondary is maybe also not inclusive-language enough.
For me the most natural way would be to describe them as 'main' and 'ports', and that's what we used most commonly everywhere so far. I just need a word for 'both'. Maybe it's just 'Architecture Policy'.
So I rename it to 'openSUSE Distribution Architecture Policy' ?
That seems like a great solution. Agree?
Calling it that makes sense. Perhaps we can go with "main" and "alternate" for architectures, since that makes more sense from the perspective you're talking about.
Also, wrt that document, as all documents tend to in wikis, it's out of date. :)
There is no concept of non-blocking architectures in Fedora anymore. That document talks about an era where architectures were separated into different Koji instances and different teams manage it. This hasn't been the case for a few years now, and all architectures are equally supported and equally blocking for every package build.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri 2020-07-03, Neal Gompa wrote:
I think we should just straight up drop this idea of tiering. Is there a good reason we can't just go with primary and secondary architectures as other distros (Debian, Fedora, etc.) do?
I don't know what inspired Dirk, but FreeBSD, for example, has https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.... and https://www.freebsd.org/platforms/
My primary input on naming is to avoid "premium". Beyond that, I go with Shakespeare: "A rose by another name" ;-)
Gerald
On Fri, 2020-07-03 at 18:30 +0200, Gerald Pfeifer wrote:
On Fri 2020-07-03, Neal Gompa wrote:
I think we should just straight up drop this idea of tiering. Is there a good reason we can't just go with primary and secondary architectures as other distros (Debian, Fedora, etc.) do?
I don't know what inspired Dirk, but FreeBSD, for example, has https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.... and https://www.freebsd.org/platforms/
My primary input on naming is to avoid "premium". Beyond that, I go with Shakespeare: "A rose by another name" ;-)
Definitely not the Goal Gerald, I was able to get information from non- SSE components (e.g. KDE) that aarch64 can be supported.
I suppose I couldn't get such confirmation e.g. on RISC V. So this is a pledge to user, that we "are able to" provide the best effort on supporting the software.
Gerald
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On 7/7/20 12:59 PM, Lubos Kocman wrote:
Definitely not the Goal Gerald, I was able to get information from non- SSE components (e.g. KDE) that aarch64 can be supported.
I suppose I couldn't get such confirmation e.g. on RISC V. So this is a pledge to user, that we "are able to" provide the best effort on supporting the software.
Neither ARM64 nor RISC-V are really problematic platforms as both have extrem good upstream support for nearly every project that I know of.
RISC-V is currently missing Chromium, Javascript and OpenJDK JIT support, but the rest is pretty much there.
Adrian
On Friday 2020-07-03 18:02, Neal Gompa wrote:
We can use "main" and "alternative" if "primary" and "secondary" make people uncomfortable.
The terms "main" and "alternative" also make some people uncomfortable.
Hi Jan,
We can use "main" and "alternative" if "primary" and "secondary" make people uncomfortable.
The terms "main" and "alternative" also make some people uncomfortable.
Currently I'm considering the best options:
'Primary Architecture' and 'Architecture port'.
I've updated https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy to remove any mentions of 'main' and 'Tiers' (I did not yet want to rename the page).
On Fri, Jul 3, 2020 at 1:10 PM Dirk Müller dirk@dmllr.de wrote:
Hi Jan,
We can use "main" and "alternative" if "primary" and "secondary" make people uncomfortable.
The terms "main" and "alternative" also make some people uncomfortable.
Currently I'm considering the best options:
'Primary Architecture' and 'Architecture port'.
To me, this doesn't make sense because they're both ports, in essence.
Hi Neal,
Am Fr., 3. Juli 2020 um 20:11 Uhr schrieb Neal Gompa ngompa13@gmail.com:
'Primary Architecture' and 'Architecture port'.
To me, this doesn't make sense because they're both ports, in essence.
Only one of the two is called that way ;)
I admit I'm lacking a better wording. I am struggling with the Fedora and Debian wordings (and I think I mentioned that in an earlier email), and 'port' however bad or misplaced it may be, at least has some 'openSUSE' historic meaning (and as I got pointed out, this conflicts quite a bit with the *BSD definition of ports).
I don't want this to become a naming bikeshedding exercise, so if anyone has a better suggestion, I happily take it. Otherwise thats what it is for now.
Greetings, Dirk
On Fri, Jul 3, 2020 at 3:54 PM Dirk Müller dirk@dmllr.de wrote:
Hi Neal,
Am Fr., 3. Juli 2020 um 20:11 Uhr schrieb Neal Gompa ngompa13@gmail.com:
'Primary Architecture' and 'Architecture port'.
To me, this doesn't make sense because they're both ports, in essence.
Only one of the two is called that way ;)
I admit I'm lacking a better wording. I am struggling with the Fedora and Debian wordings (and I think I mentioned that in an earlier email), and 'port' however bad or misplaced it may be, at least has some 'openSUSE' historic meaning (and as I got pointed out, this conflicts quite a bit with the *BSD definition of ports).
I don't want this to become a naming bikeshedding exercise, so if anyone has a better suggestion, I happily take it. Otherwise thats what it is for now.
What do we need the distinction for?
On 7/4/20 9:33 PM, Neal Gompa wrote:
On Fri, Jul 3, 2020 at 3:54 PM Dirk Müller dirk@dmllr.de wrote:
Hi Neal,
Am Fr., 3. Juli 2020 um 20:11 Uhr schrieb Neal Gompa ngompa13@gmail.com:
'Primary Architecture' and 'Architecture port'.
To me, this doesn't make sense because they're both ports, in essence.
Only one of the two is called that way ;)
I admit I'm lacking a better wording. I am struggling with the Fedora and Debian wordings (and I think I mentioned that in an earlier email), and 'port' however bad or misplaced it may be, at least has some 'openSUSE' historic meaning (and as I got pointed out, this conflicts quite a bit with the *BSD definition of ports).
I don't want this to become a naming bikeshedding exercise, so if anyone has a better suggestion, I happily take it. Otherwise thats what it is for now.
What do we need the distinction for?
We don't support all Architectures equally, having a clear way to show users what level of support they can expect for each architecture seems pretty sensible, maybe you could get away from needing to come up with names by providing some form of reference table instead, but 2 categories with names probably meets our current needs.
Hello,
Am Freitag, 3. Juli 2020, 18:50:32 CEST schrieb Jan Engelhardt:
On Friday 2020-07-03 18:02, Neal Gompa wrote:
We can use "main" and "alternative" if "primary" and "secondary" make people uncomfortable.
The terms "main" and "alternative" also make some people uncomfortable.
What about "main architectures" and "additional architectures"?
Regards,
Christian Boltz
PS: non-random signature ;-)
On Sat, Jul 4, 2020 at 1:16 PM Christian Boltz opensuse@cboltz.de wrote:
Hello,
Am Freitag, 3. Juli 2020, 18:50:32 CEST schrieb Jan Engelhardt:
On Friday 2020-07-03 18:02, Neal Gompa wrote:
We can use "main" and "alternative" if "primary" and "secondary" make people uncomfortable.
The terms "main" and "alternative" also make some people uncomfortable.
What about "main architectures" and "additional architectures"?
I'd be good with this terminology.
On Saturday 2020-07-04 19:15, Christian Boltz wrote:
Am Freitag, 3. Juli 2020, 18:50:32 CEST schrieb Jan Engelhardt:
On Friday 2020-07-03 18:02, Neal Gompa wrote:
We can use "main" and "alternative" if "primary" and "secondary" make people uncomfortable.
The terms "main" and "alternative" also make some people uncomfortable.
What about "main architectures" and "additional architectures"?
My point was that there will always be someone uncomfortable/offended/etc.
Having multiple tiers of architectures is by its very essence a discrimination. *Any* words you pick will serve as a discriminator for the matter at hand. Attempting to pick discriminatory-free words is futile[1]. So perhaps now we can stop wasting Dirk's time.
[1] confer with the example(s) at https://github.com/blacklistisnotracist/the-most-politically-correct-softwar...
On Sat, Jul 4, 2020 at 20:44, Jan Engelhardt jengelh@inai.de wrote:
My point was that there will always be someone uncomfortable/offended/etc.
Having multiple tiers of architectures is by its very essence a discrimination. *Any* words you pick will serve as a discriminator for the matter at hand. Attempting to pick discriminatory-free words is futile[1]. So perhaps now we can stop wasting Dirk's time.
[1] confer with the example(s) at https://github.com/blacklistisnotracist/the-most-politically-correct-softwar...
Well, it doesn't hurt to try, it hurts others if we don't try though.
LCP [Stasiek] https://lcp.world
Hi all,
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Thanks to all who provided feedback. I've incorporated all of it and updated it to 20200703 now:
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
I consider this the final draft.
Please provide any feedback you might have until July 10th.
Thanks a lot in advance! Dirk
Hi,
On 7/3/20 1:11 PM, Dirk Müller wrote:
Hi all,
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Thanks to all who provided feedback. I've incorporated all of it and updated it to 20200703 now:
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
I consider this the final draft.
Please provide any feedback you might have until July 10th.
Well,
""" The distribution maintainers are filing bugreports on https://bugzilla.opensuse.org/ for package maintainers if there are issues identified in the architecture port. The package maintainers commit to handle primary architectures with care and test-build them in the development projects before submitting changes. The package maintainers commit to handle regressions quickly and in general accept bugreports for that platform and work on a resolution. """
Basically states that a relatively small group of people gets to decree what I as a maintainer do with my time. I am __not__ OK with that. By example.
Let's say that "fancy new chip maker" decides they want openSUSE to run on their "fancy new I promise it's much better" chip. Based on this document all that is needed from "fancy new chip maker" is to put up an architecture team and put it up for discussion. As long as the architecture team exists and the guidelines are met there is no exit condition and thus if the guidelines are met there is no way, according to the proposal to say "No". What that means is that a small group of 4 or 5 people get to commandeer the time of 100s of volunteers because once the port is primary all package maintainers get committed per the guidelines. I don't think so.
As a package maintainer I either get a say in the work I am committing to or I will simply flip those that think they can commandeer my time the bird.
So I think we need an exit condition. I realize that consensus is extremely hard to gauge in an ML discussion, but we have to try. The current guideline states nothing about any type of influence of the ML discussion, it simply states that
""" Any nomination for a primary architecture should be brought up for discussion on the respective openSUSE distribution mailing list and also announced on the opensuse-project@ mailing list. """
So the architecture team from "fancy new chipmaker" simply posts a couple of messages and the ensuing discussions have no influence. That's not how it should work, IMHO. If the support is not there then the architecture team of "fancy new chipmaker" shouldn't get to claim "we followed the guidelines now we have to be primary".
In short I think there needs to be a lot more clarity about the nomination process and what the acceptance criteria are. Which should be more than following the proposed guidelines.
Later, Robert
Hi Robert
On 7/6/20 11:44 AM, Robert Schweikert wrote:
Hi,
On 7/3/20 1:11 PM, Dirk Müller wrote:
Hi all,
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Thanks to all who provided feedback. I've incorporated all of it and updated it to 20200703 now:
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
I consider this the final draft.
Please provide any feedback you might have until July 10th.
Well,
""" The distribution maintainers are filing bugreports on https://bugzilla.opensuse.org/ for package maintainers if there are issues identified in the architecture port. The package maintainers commit to handle primary architectures with care and test-build them in the development projects before submitting changes. The package maintainers commit to handle regressions quickly and in general accept bugreports for that platform and work on a resolution. """
Basically states that a relatively small group of people gets to decree what I as a maintainer do with my time. I am __not__ OK with that. By example.
Let's say that "fancy new chip maker" decides they want openSUSE to run on their "fancy new I promise it's much better" chip. Based on this document all that is needed from "fancy new chip maker" is to put up an architecture team and put it up for discussion. As long as the architecture team exists and the guidelines are met there is no exit condition and thus if the guidelines are met there is no way, according to the proposal to say "No". What that means is that a small group of 4 or 5 people get to commandeer the time of 100s of volunteers because once the port is primary all package maintainers get committed per the guidelines. I don't think so.
As a package maintainer I either get a say in the work I am committing to or I will simply flip those that think they can commandeer my time the bird.
So I think we need an exit condition. I realize that consensus is extremely hard to gauge in an ML discussion, but we have to try. The current guideline states nothing about any type of influence of the ML discussion, it simply states that
""" Any nomination for a primary architecture should be brought up for discussion on the respective openSUSE distribution mailing list and also announced on the opensuse-project@ mailing list. """
So the architecture team from "fancy new chipmaker" simply posts a couple of messages and the ensuing discussions have no influence. That's not how it should work, IMHO. If the support is not there then the architecture team of "fancy new chipmaker" shouldn't get to claim "we followed the guidelines now we have to be primary".
In short I think there needs to be a lot more clarity about the nomination process and what the acceptance criteria are. Which should be more than following the proposed guidelines.
I think you may have missed one of the more major requirements, which is a significant percentage of the distro needs to be building and passing QA under these guidelines. That really means a team can't just show up out of know where, they have to put in the effort fix any of the major issues etc and have everything working. Presumably if you have an arch dependent bug that you can't fix they would also be willing to help because if enough people didn't have time and the percentage of packages building dropped significantly.
So I don't really think its possible under these rules for a chip manufacturer to come in create a team then expect you to do all the work or even most of it, Beyond accepting the occasional request and then maybe handling the occasional architecture specific bug atleast to the point of asking for help.
Hi Robert,
Basically states that a relatively small group of people gets to decree what I as a maintainer do with my time. I am __not__ OK with that. By example.
Well, I agree there is a trade-off balance in the draft, however I think it's a good one. The prerequisites of becoming a primary architecture have to be met, which means it has to have good (passing) openqa coverage, good build-from-source results and it has to have an active set of maintainers caring about that particular architecture.
Under those circumstances, are you still considering this an invasion into your personal freedom of a package maintainer to care or not care about a particular architecture? I think this is the part where a distribution does have to level-set its expectations somewhat, and say what it cares about and what it doesn't care about. This is the core part of the policy.
Let's say that "fancy new chip maker" decides they want openSUSE to run on their "fancy new I promise it's much better" chip. Based on this document all that is needed from "fancy new chip maker" is to put up an architecture team and put it up for discussion.
I find this discussion slightly superficial, so I find it hard to respond constructively. The reason for that is that yes, there is a chance for an abuse here, but if you compare the cost of rolling out a new architecture (which includes but not limited to, designing a new ISA, making it work, building it, convince ecosystem partners to embrace it, build a toolchain, bootstrap it, land support in the various relevant projects upstream (including but not limited to the Linux kernel and the GNU stack of projects)) with the damage produced on the openSUSE package maintainers, those two don't quite compare.
We've seen by practical examples that this is an effort of at least 5, probably more like 10 years to introduce a new architecture until it can become a candidate for a primary architecture nomination. And this is a factor of cost of 5+ years for hundreds, probably thousands of engineers, all done on purpose just to make you, Robert, the openSUSE package maintainer, and your life miserable. I have a hard time believing somebody would be willing to fund such an experiment just for that purpose.
But to turn it around, what is your suggestion on a better balance on what a primary architecture means ?
architecture team exists and the guidelines are met there is no exit condition and thus if the guidelines are met there is no way, according to the proposal to say "No". What that means is that a small group of 4 or 5 people get to commandeer the time of 100s of volunteers because once the port is primary all package maintainers get committed per the guidelines. I don't think so.
So you're missing one aspect. what is it? adoption of the architecture? user popularity? availability of hardware environments?
So the architecture team from "fancy new chipmaker" simply posts a couple of messages and the ensuing discussions have no influence.
It is more than that, they also have to bootstrap and maintain a port as an additional architecture successfully for a period of time to be able to do the nomination. We can specify the period of time the additional architecture has to be 'following the primary architecture' guidelines already if that's what you're looking for.
not how it should work, IMHO. If the support is not there then the architecture team of "fancy new chipmaker" shouldn't get to claim "we followed the guidelines now we have to be primary".
No, reverse logic does not apply. The answer to the discussion can still be no.
In short I think there needs to be a lot more clarity about the nomination process and what the acceptance criteria are. Which should be more than following the proposed guidelines.
I'm struggling to come up with a good acceptance criteria. Do you have a good suggestion?
From an informal discussion with a few folks, people rejected the idea
of having a vote. There is no benevolent-dictator-for-life in openSUSE, so in lacking of those two options, the best process process that I can come up with is the lazy-consensus model ( http://www.apache.org/foundation/glossary.html#LazyConsensus ). This is a popular model under which many open source projects are operating so I was hoping for this to be widely accepted, as it follows 'the one who works decides' mantra.
Greetings, Dirk
Am 03.07.20 um 19:11 schrieb Dirk Müller:
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Thanks to all who provided feedback. I've incorporated all of it and updated it to 20200703 now:
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
I consider this the final draft.
Please provide any feedback you might have until July 10th.
The document explains a list of checkmark items that are required to be fulfilled in order to be able to apply to becoming a primary architecture, right?
What's the outcome of an approval to become primary though?
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
cu Ludwig
On Mon, 2020-07-06 at 15:04 +0200, Ludwig Nussel wrote:
Am 03.07.20 um 19:11 schrieb Dirk Müller:
I would like to get your input and start a discussion around :
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
Thanks to all who provided feedback. I've incorporated all of it and updated it to 20200703 now:
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy
I consider this the final draft.
Please provide any feedback you might have until July 10th.
The document explains a list of checkmark items that are required to be fulfilled in order to be able to apply to becoming a primary architecture, right?
What's the outcome of an approval to become primary though?
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
Not sure about Factory, my expecation is that we're doing this for Leap, but we make the checklist generic so it can be applied anywhere.
For leap it would be the equivalent of what you suggest, and that's transition from ports to stanard. Adding arm deliverables to the stanard release activities etc.
cu Ludwig
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Mon, 2020-07-06 at 15:04 +0200, Ludwig Nussel wrote:
The document explains a list of checkmark items that are required to be fulfilled in order to be able to apply to becoming a primary architecture, right?
What's the outcome of an approval to become primary though?
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
We made the experiment with ppc64le in rings/stagings - and frankly, with the current worker-pool, this became more than just an annoyance. The more we enabled ppc64le in the stagings, obviously, more devel projects enabled ppc64le as well, further putting strain on the already limited worker pool. It was not uncommon that x86_64/i586 builds were completed > 48 hours earlier than ppc64le in a staging (and that was at the time where I had 10 TW stagings, now we're at 15 + Gcc)
If getting those archs as part of /standard and thus staging is a requirement, we clearly need also some words about worker-pool-size here.
Also, the more archs we add to /standard, the larger the worker needed to build the FTP Tree (keep in mind that it caches all packages from all archs, meaning src/noarch packages exist in as many archs, even though only one ends up in the repo in the end - but the worker needs the disk space - plus it increases the time to cache the stuff on the worker and build the product)
Cheers, Dominique
Dominique Leuenberger / DimStar wrote:
On Mon, 2020-07-06 at 15:04 +0200, Ludwig Nussel wrote:
The document explains a list of checkmark items that are required to be fulfilled in order to be able to apply to becoming a primary architecture, right?
What's the outcome of an approval to become primary though?
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
We made the experiment with ppc64le in rings/stagings - and frankly, with the current worker-pool, this became more than just an annoyance. The more we enabled ppc64le in the stagings, obviously, more devel projects enabled ppc64le as well, further putting strain on the already limited worker pool. It was not uncommon that x86_64/i586 builds were completed > 48 hours earlier than ppc64le in a staging (and that was at the time where I had 10 TW stagings, now we're at 15 + Gcc)
If getting those archs as part of /standard and thus staging is a requirement, we clearly need also some words about worker-pool-size here.
Also, the more archs we add to /standard, the larger the worker needed to build the FTP Tree (keep in mind that it caches all packages from all archs, meaning src/noarch packages exist in as many archs, even though only one ends up in the repo in the end - but the worker needs the disk space - plus it increases the time to cache the stuff on the worker and build the product)
So what is the conclusion from that?
We can't actually afford to promote any other arch than x86_64 to primary due to those constraints?
The proposed policy needs to be extended to also require sufficient OBS resources?
cu Ludwig
On Tue, Jul 14, 2020 at 10:30 AM Ludwig Nussel ludwig.nussel@suse.de wrote:
Dominique Leuenberger / DimStar wrote:
On Mon, 2020-07-06 at 15:04 +0200, Ludwig Nussel wrote:
The document explains a list of checkmark items that are required to be fulfilled in order to be able to apply to becoming a primary architecture, right?
What's the outcome of an approval to become primary though?
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
We made the experiment with ppc64le in rings/stagings - and frankly, with the current worker-pool, this became more than just an annoyance. The more we enabled ppc64le in the stagings, obviously, more devel projects enabled ppc64le as well, further putting strain on the already limited worker pool. It was not uncommon that x86_64/i586 builds were completed > 48 hours earlier than ppc64le in a staging (and that was at the time where I had 10 TW stagings, now we're at 15 + Gcc)
If getting those archs as part of /standard and thus staging is a requirement, we clearly need also some words about worker-pool-size here.
Also, the more archs we add to /standard, the larger the worker needed to build the FTP Tree (keep in mind that it caches all packages from all archs, meaning src/noarch packages exist in as many archs, even though only one ends up in the repo in the end - but the worker needs the disk space - plus it increases the time to cache the stuff on the worker and build the product)
So what is the conclusion from that?
We can't actually afford to promote any other arch than x86_64 to primary due to those constraints?
The proposed policy needs to be extended to also require sufficient OBS resources?
To me, it sounds like the conclusion is *real* architecture support for openSUSE is a fantasy, because you cannot make it work top-level. I would agree that any architecture you want to consider "primary" or "main" or whatever needs to be in "openSUSE:Factory" for Tumbleweed, and "openSUSE:Leap:<version>" for the openSUSE Leap version.
Ideally, there should be no Ports project at all anymore, and all architectures would be built through the main one.
On Tue, 2020-07-14 at 11:27 -0400, Neal Gompa wrote:
On Tue, Jul 14, 2020 at 10:30 AM Ludwig Nussel <ludwig.nussel@suse.de
wrote: Dominique Leuenberger / DimStar wrote:
On Mon, 2020-07-06 at 15:04 +0200, Ludwig Nussel wrote:
The document explains a list of checkmark items that are required to be fulfilled in order to be able to apply to becoming a primary architecture, right?
What's the outcome of an approval to become primary though?
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
We made the experiment with ppc64le in rings/stagings - and frankly, with the current worker-pool, this became more than just an annoyance. The more we enabled ppc64le in the stagings, obviously, more devel projects enabled ppc64le as well, further putting strain on the already limited worker pool. It was not uncommon that x86_64/i586 builds were completed > 48 hours earlier than ppc64le in a staging (and that was at the time where I had 10 TW stagings, now we're at 15 + Gcc)
If getting those archs as part of /standard and thus staging is a requirement, we clearly need also some words about worker-pool- size here.
Also, the more archs we add to /standard, the larger the worker needed to build the FTP Tree (keep in mind that it caches all packages from all archs, meaning src/noarch packages exist in as many archs, even though only one ends up in the repo in the end - but the worker needs the disk space - plus it increases the time to cache the stuff on the worker and build the product)
So what is the conclusion from that?
We can't actually afford to promote any other arch than x86_64 to primary due to those constraints?
The proposed policy needs to be extended to also require sufficient OBS resources?
To me, it sounds like the conclusion is *real* architecture support for openSUSE is a fantasy, because you cannot make it work top-level. I would agree that any architecture you want to consider "primary" or "main" or whatever needs to be in "openSUSE:Factory" for Tumbleweed, and "openSUSE:Leap:<version>" for the openSUSE Leap version.
Ideally, there should be no Ports project at all anymore, and all architectures would be built through the main one.
Keep in mind that we still have 32bit ARM and RISC-V.
-- 真実はいつも一つ！/ Always, there's only one truth!
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Hi Ludwig,
Am Di., 14. Juli 2020 um 16:30 Uhr schrieb Ludwig Nussel ludwig.nussel@suse.de:
The proposed policy needs to be extended to also require sufficient OBS resources?
It is in there, indirectly (needs to release frequently, needs to be trigger releases on openqa coverage, needs to have good testing coverage). None of that can be achieved without sufficient resources (both human capital in the form of people hunting for regressions as well as physical resources like build and test automation power).
I think we can define the 'staging or not' requirements in a followup policy that is tumbleweed specific.
Greetings, Dirk
Let me re-start the discussion
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy mentioned date 10th of July. I suppose that was the end date to either approve or disapprove.
Dirk can you summarize where we are based on the feedback that we have received? We could distribute action items and keep effort rolling.
Thank you
Lubos N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Tiers_Policy mentioned date 10th of July. I suppose that was the end date to either approve or disapprove.
Hi Lubos,
thanks for taking up this topic. I've been distracted by other things, and only now resumed on this mail thread. The summary here is that there was no additional feedback, so I took the liberty to roll out the remaining change requests:
* Remove problematic "Tiers/Primary" architecture wording and replace it with "Main architecture" and "Additional Architecture".
* Consequently I had to rename the policy itself as well. it is now called: https://en.opensuse.org/openSUSE:OpenSUSE_Distribution_Architectures_Policy
* In addition I splitted the Tumbleweed rules into a subtopic together (no rewordings, just regroupings) and added one rule, as requested by Ludwig:
''' The Tumbleweed version of the distribution is taking appropriate measures to keep Ring 0 and Ring 1 packages buildable from source at any point in time. This can be for example by ensuring that no package source enters that would fail significant parts of the Rings, or can be by backing out problematic changes until the underlying issue has been fixed. '''
One way to read it is that there could be Stagings for those architecture. another way is that we take appropriate measures by ensuring that packages for main architectures are building for *all* the main architectures in the devel project at the time of submission, and that the Rings are regularly monitored for regressions. In case there are regressions, we'll address it or back out problematic changes.
As it is a living document, I took the liberty to remove the "draft" comment, given that I think we reached enough consent to move forward.
Thanks everyone for the help on achieving this!
Greetings, Dirk
-----Original Message----- From: Dominique Leuenberger / DimStar dimstar@opensuse.org Sent: 14 July 2020 12:12 To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Re: [RFC] OpenSUSE Distribution Tiers Policy
On Mon, 2020-07-06 at 15:04 +0200, Ludwig Nussel wrote:
The document explains a list of checkmark items that are required to be fulfilled in order to be able to apply to becoming a primary architecture, right?
What's the outcome of an approval to become primary though?
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
We made the experiment with ppc64le in rings/stagings - and frankly, with the current worker-pool, this became more than just an annoyance. The more we enabled ppc64le in the stagings, obviously, more devel projects enabled ppc64le as well, further putting strain on the already limited worker pool. It was not uncommon that x86_64/i586 builds were completed > 48 hours earlier than ppc64le in a staging (and that was at the time where I had 10 TW stagings, now we're at 15 + Gcc)
If getting those archs as part of /standard and thus staging is a requirement, we clearly need also some words about worker-pool-size here.
Also, the more archs we add to /standard, the larger the worker needed to build the FTP Tree (keep in mind that it caches all packages from all archs, meaning src/noarch packages exist in as many archs, even though only one ends up in the repo in the end - but the worker needs the disk space - plus it increases the time to cache the stuff on the worker and build the product)
I do not think having stagings and all in /standard is a hard requirement to be a supported architecture. Stagings projects are there to catch problems earlier. In most cases, build/dependencies problems caught by x86 stagings also cover other architectures, so no need to duplicate this on other archs, I think. But having openQA with a good coverage as a gatekeeper is clearly mandatory.
Cheers, Guillaume
Cheers, Dominique
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Wednesday, 15 July 2020 09.15.33 CEST Guillaume Gardet wrote:
-----Original Message----- From: Dominique Leuenberger / DimStar dimstar@opensuse.org Sent: 14 July 2020 12:12 To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Re: [RFC] OpenSUSE Distribution Tiers Policy
On Mon, 2020-07-06 at 15:04 +0200, Ludwig Nussel wrote:
The document explains a list of checkmark items that are required to be fulfilled in order to be able to apply to becoming a primary architecture, right?
What's the outcome of an approval to become primary though?
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
We made the experiment with ppc64le in rings/stagings - and frankly, with the
current worker-pool, this became more than just an annoyance.
The more we enabled ppc64le in the stagings, obviously, more devel projects
enabled ppc64le as well, further putting strain on the already
limited worker pool. It was not uncommon that x86_64/i586 builds were completed > 48 hours earlier than ppc64le in a staging (and that was at the time where I had 10 TW stagings, now we're at 15 + Gcc)
If getting those archs as part of /standard and thus staging is a requirement, we clearly need also some words about worker-pool-size here.
Also, the more archs we add to /standard, the larger the worker needed to build the FTP Tree (keep in mind that it caches all packages from all archs, meaning src/noarch packages exist in as many archs, even though only one ends up in the repo in the end - but the worker needs the disk space - plus it increases the time to cache the stuff on the worker and build the product)
I do not think having stagings and all in /standard is a hard requirement to be a supported architecture. Stagings projects are there to catch problems earlier. In most cases, build/dependencies problems caught by x86 stagings also cover other architectures, so no need to duplicate this on other archs, I think. But having openQA with a good coverage as a gatekeeper is clearly mandatory.
Exactly. That is in principle not a problem but same as OBS hardware ressources we also have to keep openQA hardware ressources in mind. Currently we have multiple machines for x86_64 (including 32bit) but only a single machine for ppc64le so no redundancy. For aarch64 we have a single dedicated machine plus extended ressources in public cloud as setup by Guillaume in a beautiful way :)
Hi Ludwig,
Am Mo., 6. Juli 2020 um 15:04 Uhr schrieb Ludwig Nussel ludwig.nussel@suse.de:
What's the outcome of an approval to become primary though?
The policy is intended as a framework for more specific guidelines, that the Leap and Factory maintainers can draft or implement based on the outcome of the policy decision.
Ie after aarch64 gets promoted to primary, will it be removed from openSUSE:Factory:ARM and be and added to the "standard" repo in openSUSE:Factory? Will staging projects, including ADI build aarch64?
I know everything has to be a tools and hardware resource discussion at some point, and I'm looking forward to that, but for the scope of the policy that is currently not in scope. To answer your question more concretely: That's up to the particular distribution maintainers to decide. I see for example the need for staging support to be different between leap and Factory, for example, just by the nature of how things are handled regarding stability vs updating.
The outcome of the policy is that 'labelling' that it is a primary architecture, with the consequences:
* it gets equal treatment by the package maintainers and the distribution maintainers regards to regressions and building state amongst all the primary architectures (like for example a submission that regresses on one primary architecture can be rejected)
* if a particular architecture no longer is primary because it falls behind the minimum requirements (like no active maintenance, or lack of releases, lack of openqa passes), it can be downgraded again.
Greetings, Dirk
-
Aaron Puchert -
Andreas Schwab -
Christian Boltz -
Dirk Müller -
Dominique Leuenberger / DimStar -
Gerald Pfeifer -
Guillaume Gardet -
Jan Engelhardt -
Jason Craig -
John Paul Adrian Glaubitz -
Lubos Kocman -
Ludwig Nussel -
Michal Kubecek -
Neal Gompa -
Oliver Kurz -
Robert Schweikert -
Simon Lees -
Stasiek Michalski