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.
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. / b...@redhat.com
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
