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

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 -- 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 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 Fr., 26. Juni 2020 um 17:04 Uhr schrieb Jason Craig :

May I suggest the wording "should always be successfully re-buildable".

Thanks - yes that makes sense. I've updated the wording. 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 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 Aaron, Am Do., 18. Juni 2020 um 01:53 Uhr schrieb Aaron Puchert :

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 -- 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 11:59 AM Gerald Pfeifer 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! -- 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 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

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). -- 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, 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 -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo

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

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

On Tue, 2020-07-14 at 11:27 -0400, Neal Gompa wrote:

On Tue, Jul 14, 2020 at 10:30 AM Ludwig Nussel

...

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

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

-----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 Ludwig, Am Mo., 6. Juli 2020 um 15:04 Uhr schrieb Ludwig Nussel :

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