ARM as a primary architecture

[Peter Jones]

On 03/20/2012 12:30 PM, Jon Masters wrote:
> Hi again,
> 
> I want to thank you, and everyone else in FESCo for talking with us
> yesterday, and for looking over the proposal. Bear in mind, it's a work
> in progress. We intend to have broader conversations over the coming
> months and F18 is an optimistic goal. Nonetheless, I feel it is
> achievable (we've done many more disruptive things!) but we have also
> many points along the way at which we can back out, and remain SA.
> 
> To address a few of these points...at least, I'll try :) First, just to
> repeat, we took the proposal to FESCo yesterday in the spirit of "early
> and often", not in the spirit of "final deliverable". Therefore, while
> it is true we've not yet reached out to everyone for input, that is
> because it is still a work in progress for us. We'll iterate based on
> feedback, and based upon yesterday and reaching out to other groups.
> 
> On 03/20/2012 11:52 AM, Peter Jones wrote:
> 
>> 1) mechanisms need to be in place to get package maintainers access to fix
>>     arm-specific bugs in their packages
> 
> So we have a tracker bug at the moment. Is that sufficient? If so, we
> obviously should make sure that it is included in the proposal docs that
> we have this in place and are using it.

No, that's not sufficient.  The plan can't be "if you have a bug that only
shows up on arm, you file a bug and help you out."  Part of what being a
primary architecture means is enabling package maintainers to do the
maintenance on their package.  That's why, for example, secondary arch
maintainers have wide commit approval, but there's no such concept for
primary architectures.

>> 2) excludearch is not an option.  This is fundamentally contrary to being
>>     a primary arch. In fact this is one of the defining characteristics of
>>     a secondary arch.
> 
> Let's think about this some. ARM (32-bit) doesn't do Intel-style
> microcode, MCE, or many other things that x86 does. I don't think that
> means we should build packages that are x86-specific for ARM systems.

The proposal didn't suggest this, and that wasn't what I was referring to
either. The specific phrasing you guys used was "Any packages that fail to
build on ARM are marked with excludearch by a proven packager."  This is
not okay. Packages that are truly x86 specific - and I'm not talking about
incidental build failures due to bugs - should already have ExclusiveArch
tags in them limiting them to that architecture.

> We generally believe that we're starting from a point of good
> momentum, but there are some packages that won't ever be appropriate
> for ARM, and there are others where the FTBFS has been longstanding,
> or there are other (IMO valid) reasons why it might initially be
> Exclude.

And again, we're not talking about packages that are wholly inappropriate.

> That doesn't mean that there would be many such cases. Nonetheless,
> I think it would be unreasonable to set the entry bar so high that 
> there can be no things left to fix. That basically retains the x86 
> monopoly.

I don't mean to be saying there can't be outstanding bugs, but that's not
what you're saying either.  Adding ExclusiveArch to packages which are meant
to eventually work is a form of papering over the problems.  It's one thing
to have outstanding issues; it's another thing to introduce non-fixes into
packages for those issues.

>> 3) arm must be integrated to the formal release criteria
> 
> Agreed. We'll need to figure that out.
> 
>> 4) when milestones occur, arm needs to be just as testible as other
>>     primary architectures
> 
> So we have a new hire (hi Paul) who is looking at autoqa, and we're
> going to pull together as much as we can here. It would help me to know
> (and we're reaching out to QE separately - per my other mail) what you
> would consider "testable" to mean, in terms of what you'd want to see.

I'd largely defer to adamw for specific criteria regarding testing, both
in terms of criteria we're testing for (i.e. #3) and in terms of establishing
appropriate testing procedures for the platform.  I've largely listed those
because there's not really any indication in the proposal as it stands
that this is well-considered at this point in time.  There's a brief section
on how to test, but it appears to be largely pro-forma.

>> 5) installation methods must be in place.  I'm not saying it has to be
>>    using the same model as x86, but when we get to beta, if it can't be
>>    installed, it can't meet similar release criteria to existing or prior
>>    primary arches. Where possible, we should be using anaconda for
>>    installation, though I'd be open to looking at using it to build
>>    installed images for machines with severe resource constraints.
> 
> So we feel it more appropriate to use image creation tools at this
> point, for the 32-bit systems that we have in mind.

I don't disagree, and I think I made that pretty clear in all those
caveats you've generously quoted. I've heard that you've been talking to
bcl about this.  I encourage you to continue on that route.

-- 
        Peter