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!
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
