ARM as a primary architecture

[Jesse Keating]

On 3/20/12 9:30 AM, 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.

A tracker bug is certainly not sufficient.  It would be for a SA, but 
not PA.  Typically our users have a PA at their disposal, or failing 
that have ready access to a shared PA provided by the Fedora Project 
that they can log into and do their testing.

Without ARM systems available for all the releases our maintainers have 
to support this is a non-starter.  I will also note that having to 
resort to using a remote system because the arch isn't generally locally 
at a maintainer's disposal /is/ going to introduce a delay in getting 
bugs resolved and builds out the door.  If the arch was ubiquitous in a 
way that lent itself to easy debugging and use that'd be a different 
matter, but I just don't see it as being there right now.

>
>> 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. 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. 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.

Perhaps Peter can clarify or soften this requirement a bit.  EXCLUDEARCH 
as a default action when a build fails on ARM is certainly not an 
option.  What would help your situation is generating a few lists of 
packages.  One list would be packages that you feel just don't make 
sense on ARM.  Another list would be the FTBFS you mention.  These lists 
can be debated and decided upon /before/ the migration to PA and the 
ExcludeArches can be in place before the switch is pulled.

Once the switch is pulled, that's when excludearch is unacceptable 
without FESCo or such involvement, just like it is with the other 
primary arches.  That's really a price of entry.

>
>> 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 think what is meant here is that we have to be able to get the arm 
version of the rpms installed onto an appropriate host and be able to 
easily run the programs to ensure that things are working as expected, 
more than just "It built, SHIP IT".

Take a look at the release criteria we have currently have in place for 
alpha/beta/final.  ARM will need to follow it or have something 
extremely similar.  Granted the release criteria mostly involves the 
installation process, but it does include installs from live media. 
Installs /to/ a SD device and then booting said install to validate it 
could fit in there.


-- 
Jesse Keating
Fedora -- Freedom² is a feature!