On 04/04/2012 03:26 PM, Matthew Garrett wrote:
Can we quantify what the overall experience is that must be
consistent? I understand Anaconda installations is considered a
part of this... except when it's not for EC2 images. What I'm
looking for is "These 10 things are partof the Fedora experience-
any PA needs to provide at least 7 of them" or something like that.
The only differences between the Fedora experience on ARM and x86 should
be those dictated by hardware.
Just hardware, or hardware and software? Or hardware, software, and
community? If hardware is capable of providing a desktop experience,
but only with proprietary drivers, does that mean the arch isn't
acceptable as PA? What if some forms of the hardware are desktop
capable, others are not, but the community only has an interest in
supporting headless installations? I think we're all going to be
rational about this, but my rational and yours might not match up.
This makes sense, but what is adequate? Perhaps 1 distinct person
in each group saying "I will be responsible for $ARCH?" What if
only 1 person wants to be the secondary representative in both
groups?
That's something that would have to be discussed with the infrastructure
and release engineering teams.
If that's the case please spell it out:
SA must secure from the Fedora Infrastructure and Release Engineering
teams a statement that they are prepared to support the SA as PA. It us
up to these teams how to form that consensus and provide an answer. The
question should be formally posed to their respective mailing lists
unless they have an otherwise stated policy.
Or something like that.
This is overloading "support" so I'm having a little trouble
understanding the intention. Let's try a thought experiment that's
a little more generic than the above. I propose any given
architecture falls into at least 1 and possibly all 4 of the
following categories:
1. Specs not suited to Fedora at all (too little RAM, no MMU, etc)
2. Can run Fedora, but Anaconda installation doesn't make sense for
technical reasons.
3. Can run Fedora, would even benefit by Anaconda installation, but
requires changes to Anaconda and/or other packages to work.
4. Can run Fedora and Anaconda supports it fine.
I think what you're trying to express is that either 2 or 4 must be
true and that if 3 is true, 4 must also be true. Is that right?
Yes, I think that's accurate.
Okay- would you put that in the document?
All supported platforms must have kernels built from the Fedora
kernel SRPM and enabled by default in the spec file. Each kernel must
be built in a timely manner for every SRPM upload.
What exactly is timely? What margin is acceptable? Is this only
for kernel or does this apply to any package with a
much-longer-than-average build time? What would constitute being in
that class? Or should the class be critical-path packages?
Something else?
The kernel's kind of a special case due to the relatively frequent
security updates. The exact nature of what kind of speed is required
would probably need to be discussed with the kernel team.
I believe a subsequent discussion on the matter has yielded the value of
4 hours. Can the guidelines include this, perhaps with the caveat of
"At the time this draft was approved, the agreed maximum build time for
a kernel was 4 hours."
If architecture-specific issues get fixed in a timely way then the
developer resources are sufficient. I don't think it's something that
can be explicitly quantified.
Okay, you're clearly writing that with a do everything to be PA while
SA, then you'll have proved yourself mindset. That's fine, but it would
help to spell this out. You might just as well say all
architecture-specific issues are fixed before promotion may be granted.
I'm not sure that's an achievable goal, frankly, but that does seem to
be what you're saying.
Is simulated hardware acceptable? Remote-X or VNC access? Physical
hardware? What happens when a new generation of hardware comes out?
What about architectures where there is no video at all? What about
architectures where some systems have video, others don't, but the
primary use case is systems without video?
Whatever level of access is required to fix the bugs. The aim here is to
deal with architecture-specific but otherwise generic issues - if X
fails to work on a specific model then that's just a bug and it's not
the end of the world, but if X fails to work on ARM at all then that's
something that needs to be fixed. My experience of dealing with these
things is that it's pretty difficult to fix most of these bugs remotely,
so I'd probably expect that hardware be physically available to the
people who need to fix the bugs.
Would like to see clarification on whether using a simulator (with X
support) would meet this requirement. If not then the requirement is
essentially: Most packagers on the critical path must own one of these
SA-supported systems before it can be primary.
Excludearch may be used only to disable packages that are
fundamentally architecture specific.
Assuming we mean the package has architecture specific components
that either can not, or have not, been ported, agree.
I'm not enthusiastic about excludearch being used simply because a
component hasn't been ported, but I think that's probably a stronger
position than we've traditionally had so I'm probably ok with it being
used for that.
Okay, please clarify in the document.
--
Brendan Conoboy / Red Hat, Inc. / blc@xxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
