RFC: Primary architecture promotion requirements

Peter Jones pjones at redhat.com
Tue Mar 20 20:00:57 UTC 2012

On 03/20/2012 03:32 PM, Brendan Conoboy wrote:
> On 03/20/2012 12:19 PM, Jesse Keating wrote:
>> What does "better than secondary arch" mean to you? I'm really
>> struggling here.
> As an example, the same koji server handling x86 builds handling ARM
> builds. The same facilities providing power, cooling, storage.
> Subject to applicability, the same QE mechanisms being employed. The
> same release schedule. Comparable positioning on the Fedora downloads
> pages. Primary and secondary are night-and-day different, it isn't
> just the integrated build system being disconnected, it's
> end-to-end.

So, what we really need to talk about is how to make it possible to live
as a secondary arch with stricter requirements than some secondaries have.

Ultimately here the question is how to make graduated transitions from
one to the other.  But the reasons to be a primary arch can't be as a
mechanism to become good enough to be a primary arch.

Forgive me for an extended metaphor, but this is like minor league baseball.
Nobody gets promoted to the majors to learn how to be good enough for the
majors.  Exactly the same situation exists between being a secondary arch
vs a primary one - which means we need to do a much better job in
secondary land of being able to prepare something for the time when it's
appropriate to make it a primary arch. But promoting something to primary
shouldn't be the mechanism to /prepare/ it for a higher level of expectations.

>> We as a group have identified many of the roadblocks or pain points of
>> bringing arm into primary arch.
> What pain points have been described other than "I am concerned about
> the impact of builds on the whole running slower than they do now"?
> This is not a facetious question, this is really what we're trying to
> get from the thread.

Also the things I've listed before involving shared maintainership of the
whole as opposed to effectively having arch maintainers, the installation
question, and the question of what the test plans look like.  Right now
those are questions you're taking back to work on, and I understand that,
but I think it's probably the sort of thing people refer to when they say
things like the above.


What we need is either less corruption, or more chances to participate in it.

More information about the devel mailing list