Feedback on secondary architecute promotion requirements draft

[Peter Robinson]

On Wed, Apr 4, 2012 at 11:26 PM, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> On Mon, Apr 02, 2012 at 08:10:12PM -0700, Brendan Conoboy wrote:
>
>> > 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.
>
> The only differences between the Fedora experience on ARM and x86 should
> be those dictated by hardware.
>
>> > 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?
>
> That's something that would have to be discussed with the infrastructure
> and release engineering teams.

There needs to be some resilience IMO, but then there's quite a bit of
stuff that is general cross knowledge so I'm not sure it's a problem.

>> > 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?
>
> Yes, I think that's accurate.
>
>> > 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.
>
>> > 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?
>
> 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.
>
>> > 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?
>
> 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.

There's relatively cheap hardware available and a number of HW vendors
that will provide ARM HW as well so I think this should be achievable
for general HW specific things, for general arch bits the ARM qemu
support is quite good and we plan to build images that are easy to
import into virt-manager so we have a number of reasonable options
here.

>> > 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.
>
> If the source isn't compatible with Fedora packaging guidelines then we
> shouldn't be shipping the binaries unless they fall under the generic
> firmware exemption.

That is what we plan, I don't see any reasons for other exceptions.

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

Being the person that has handled the coordination and tracking of
building F-17 as of where we stand at the moment there isn't any major
exclusions from the architecture now. Of the entire 11500 odd packages
of the mainline repository we've built 10,500 of those currently,
about half of the remaining are ftbfs on mainline, and the remainder
we're working to build or are x86 or ppc. There's only a handful of
packages that aren't HW specifc I'm aware of that are currently
building on ARM, in the coming weeks I hope to have this at near to
zero with tracking bugs against those that don't.

>> > 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:
>
> There is no path to sure success. That's not how this works.

On the flip side I don't believe it's unachievable, I hope I'm not wrong.

Peter

Peter