[fedora-arm] ARM Primary FESCO discussion results, round 1

[Brendan Conoboy]

On 03/19/2012 04:46 PM, Brendan Conoboy wrote:
> How do packagers test and resolve failures on ARM if they don't own an
> ARM device?

I like Chris's suggestion of the simulator- that's good coverage.  I'd 
also support providing login hosts to... somewhere.  Seneca? Spare 
systems in PHX?  I'm not sure, but it seems like a good idea to me.

> When will server hardware be available?

During the discussion I said 2-5 months.  Notting said 2 was good, 5 was 
bad.  I'll just extrapolate that 3 is not as good and 4 isn't as bad, 
but ultimately it's going to be when the hardware is available. 
Hopefully it'll be closer to the 2 than the 5.

> Why isn't being a secondary architecture good enough?

Greater stability in PHX, faster infrastructure, wider mirror selection, 
greater credibility as a distribution.

> Why not wait for 64 bit ARM?

The mainstay of 64 bit ARM hardware won't be available for a couple 
years.  Incredible ARM systems will be available in the interim that 
Fedora can run on with comparatively little effort.  Additionally, much 
of what's needed on 64 bit ARM can be done in the 32 bit space 
(Virtualization support for instance).

> With there being so many different kernel variants, how will a kernel
> build complete in a reasonable period of time?

Beats me- every proposal is a bit hackish.

> The builds being done in Koji are great, but what is the plan for
> composes, QE and installation?

This part of the plan really needs some work.  Even our discussions 
about how to compose images isn't quite the same as how to handle QE 
when it comes time to do an alpha/beta/rc/etc.

> If Anaconda isn't used to do installations, what will be doing the
> things Anaconda does which just installing a bunch of packages doesn't?
> (I don't know what these are)

I would hope the standard image builders handle this sort of thing, but 
do not know.

> Will there be extra patches in the kernel to enable new vendors' ARM
> processors or will upstream continue to be the way?

Jon answered that it will be upstream only. I agree.  Same policy as x86.

> What does the kernel team think about the the time required to build
> kernels on ARM? How will it affect their workflow?

I suspect Jon is going to discuss with kernel at .

> The proposal suggests building just a versatile express kernel by
> default (to save time), then using koji flags to support alternate
> kernels. Is this possible?

According to Dennis: No.  So, let's figure out how to get reasonable 
build times and good breadth on kernel builds.

> In the event that kernels are built separately per the above, what
> mechanism will be used to keep the kernels in sync?

We may need to have a less ambitious list of kernels.  Perhaps keep 
omap, tegra, highbank, but drop IMX, armada, etc.  We'll see where this 
goes.

> Assertions from the meeting:
>
> There must be a commitment of hardware both for build systems and test
> systems for PA.

In light of qemu+versatile the general test systems might be optional, 
but in principle if we have systems to spare and appropriate access 
mechanisms I don't see why not.

> Being a PA carries the obligation that all packages in Fedora will be
> available. The proposed avenue of making broken packages temporarily
> excludearch is questionable and needs work.

The thing that worries me about the excludearch is that there is no 
mechanism forcing ultimate resolution on packages which could be made to 
work on ARM.  Right now the goal of PA is a strong motivator for fixing 
packages.  If we make it to PA, how will we stay motivated?

> FTBFS issues should simply be fixed (That's not an ARM problem, but
> we're definitely impacted by it).

Suggest presenting the FTBFS list and subtracting it from the list of 
packages we need for ARM task list.

> The changes to QE, particularly because of Anaconda, will be
> substantial. This is not addressed in the proposal.

Agree. Help!

> Installability doesn't necessarily mean Anaconda (See EC2), but it does
> mean something. A real plan is called for.

We just need to formalize our plan for image generation using standard 
tools (Hopefully whatever was used for EC2 is valid here).

> All PA kernels must be derived from the same source rpm.

Yes.

...

Regarding mail to the 4 groups, What do we want to ask each of them?

Releng:

Do you have any concerns about moving ARM to PA? What are the things you 
need to see in place?  What do you not want to own?

Infrastructure:

Do we have the hardware/budget ready? What do you need in place that 
isn't now? What do you not want to own?

QE:

What do you need to do proper QE on arm? How much load will this add? 
How can we help?

Kernel:

ARM will introduce build time delays, but x86 builds will still finish 
as fast as ever.  Is this sufficient?  What do you need to see to be 
okay with ARM on PA?

-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com