Re: ARM Primary FESCO discussion results, round 1
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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@.
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.
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@xxxxxxxxxx _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm