RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Tue, Mar 20, 2012 at 02:33:57PM -0700, Brendan Conoboy wrote:

> The sense I'm getting from your reply is that the PA/SA designation
> is almost decorative, that a secondary can do anything a primary
> can, except inhibit the progress of builds.  So, if the Fedora ARM
> team fixes all broken builds, brings in all the QE mechanisms,
> engages the Fedora system at every level of the organization, solves
> the the build time performance issue, and otherwise keep at it until
> we're functionally indistinguishable from PA, *then* it's time to
> have the PA/SA discussion.  Is that right?  Speaking for myself, I
> see most of these things as a benefit of membership in PA rather
> than prerequisites.  Or more to the point, transitioning from SA to
> PA means doing all of these things, so it's really just an order of
> operations that needs to be agreed upon.

I think you're looking at this in slightly the wrong way. Being a 
primary architecture isn't meant to be a benefit to the port - it's 
meant to be a benefit to Fedora. Adding arm to the PA list means you'll 
have to take on a huge number of additional responsibilities, deal with 
more people who are unhappy about the impact upon their packages and so 
on. You get very little out of it except that there's more people to 
tell you that something's broken. The question is whether making arm a 
primary architecture makes Fedora a better distribution, and yes, in an 
ideal world arm would demonstrate that it was just as functional as x86 
before we had to make that decision.

The only reward you'll get from being a primary architecture is basking 
in the knowledge that the project thinks your work is good enough to be 
a primary architecture. The better you can demonstrate that in advance, 
the easier the process will be.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org