Feedback on secondary architecute promotion requirements draft

[Brendan Conoboy]

This is feedback vs the current version of the following web page:

http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29

It would be nice if the bullet points were numbers so they could be 
referenced numerically.

 > Promoting an architecture to primary architecture status is a
 > significant responsibility. It implies that the port is sufficiently
 > mature that little in the way of further architecture-specific
 > changes or rebuilds will be required, and also that it has enough
 > development effort to avoid it delaying the development of other
 > primary architectures.

What is "...enough development effort to avoid..."?  Perhaps this could 
be restated for clarity as a development effort is not a unit of 
measurement.

 > as such there are various expectations that the overall Fedora
 > experience will be consistent over all primary architectures.

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.

 > There must be adequate representation for the architecture on the
 > Fedora infrastructure and release engineering teams.

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?

 > All builds must occur on Fedora-maintained build servers.

FYI, this will require an additional koji-hub for each architecture 
trying to move to PA.  Generally agree, though.

 > Where technically possible, all supported hardware targets must be
 > supported via Anaconda. Exceptions are limited to highly resource
 > constrained devices or hardware which provides no means for
 > simultaneous support of install and target media.

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?

 > 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?

 > Sufficient developer resources must be available to fix any
 > architecture-specific issues in such a way that they do not delay
 > overall Fedora development.

Can you quantify this and also describe how this measurement is to be 
assessed?  Are we saying there must be X many engineers available at any 
given time to handle an architecture-specific build issue?  I don't 
believe there is a pool of x86 engineers hanging about waiting for 
inline assembler issues to come in so some discussion of the mechanics 
of what's envisioned here would be helpful.  I think the notion is that 
there must be a critical-mass of talent competent to help out, but how 
do you define that?

 > It must be possible for maintainers of critical-path hardware
 > dependent packages to have direct access to supported hardware in
 > order to rectify any release-blocking issues. For example, X
 > maintainers must have direct access to any hardware with graphics
 > capabilities.

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?

 > The port must not rely on sourceless binaries unless they fall under
 > the generic firmware exemption. Where source and toolchain are
 > available, the binaries must be built in the Fedora build
 > infrastructure.

Yes, assuming the source is compatible with Fedora packaging guidelines. 
  I'm not sure there's a case where source would be incompatible but 
binaries wouldn't be, but thought I'd mentioned it.

 > 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.

 > Installable, testable images must be generated at the normal project
 > milestones in a way that conforms to release engineering and QE
 > requirements. Where possible, image generation should be integrated
 > into the existing image generation infrastructure.

As long as the RE and QE requirements are similarly defined that's fine.

 > The architecture must meet appropriate formal release criteria

As long as the release criteria are applicable to the architecture.

 > This list is not intended to be exhaustive - promotion to primary
 > architecture status will require agreement from the Fedora
 > infrastructure, release engineering, kernel and installer teams and
 > is subject to overall approval by the Fedora Engineering Steering
 > Committee, and additional criteria may be imposed if felt to be
 > necessary.

Let's make the list exhaustive; there needs to be a path to sure 
success.  This means establishing a complete procedure where when an SA 
formally applies to become PA, acceptance means there is a definitive 
set of steps needed to get there.  This is one of the major reasons for 
developing these criteria.  Put another way:

FESCo and affected groups should have the ability to review whether or 
not the SA has in-fact fulfilled the requirements for PA, as agreed to 
by all parties at the time of application.  If those requirements are 
deemed to have been met, promotion is automatic.

There could be a deadline on application acceptance: EG, 12 months from 
acceptance of application to fulfillment of criteria.  This protects 
against criteria becoming stale.

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