Feedback on secondary architecute promotion requirements draft
This is feedback vs the current version of the following web page: http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29It 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@xxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel