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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 ;-) --

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]

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Christian, Am Mi., 17. Juni 2020 um 21:12 Uhr schrieb Christian Boltz : 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Christian, Am Do., 18. Juni 2020 um 21:34 Uhr schrieb Christian Boltz :

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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.

From a messaging perspective, I recommend not to call the other

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. ;-) 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 -- Dr. Gerald Pfeifer , CTO @SUSE + chair @openSUSE

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Jul 3, 2020 at 12:29 PM Dirk Müller 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. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Neal, Am Fr., 3. Juli 2020 um 20:11 Uhr schrieb Neal Gompa :

...

'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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 7/4/20 9:33 PM, Neal Gompa wrote:

On Fri, Jul 3, 2020 at 3:54 PM Dirk Müller wrote:

...

Hi Neal,

Am Fr., 3. Juli 2020 um 20:11 Uhr schrieb Neal Gompa :

...

...

'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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Sat, Jul 4, 2020 at 1:16 PM Christian Boltz 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. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Jul 4, 2020 at 20:44, Jan Engelhardt 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

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 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�����Ǩ�

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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----Original Message----- From: Dominique Leuenberger / DimStar 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.

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.

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,

I'm struggling to come up with a good acceptance criteria. Do you have a good suggestion? 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Ludwig, Am Di., 14. Juli 2020 um 16:30 Uhr schrieb Ludwig Nussel :

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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�����Ǩ�