Feedback on secondary architecute promotion requirements draft

[Miloslav Trmač]

On Tue, Apr 3, 2012 at 5:10 AM, Brendan Conoboy <blc at redhat.com> 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.

All architectures are built from the same SRPMs, so the overall
experience is sort of consistent by default.  7/10 is certainly not
enough, I'd assume >98% - only a few named exceptions, and the ARM
team probably knows what these are better than I do :)

This could be construed to mean "the secondary architecture will have
a comparable 3D support to the primary so that gnome-shell performs
comparably", but that's way out of scope I think.  In any case, the
true requirements start with the bullet list.


>> There must be adequate representation for the architecture on the
>> Fedora infrastructure and release engineering teams.
>
> This makes sense, but what is adequate?

I think this is left to be decided by the infrastructure and rel-eng teams.


>> The architecture must meet appropriate formal release criteria
>
> As long as the release criteria are applicable to the architecture.

I actually think this requirement is too strict most of the time - the
primary architectures need weeks of bug fixing to meet the release
criteria :)  I'm not sure about a better way to word it, though.
Perhaps this just means that the PA promotion decision would have take
place at the same time that the next beta release meets release
criteria.


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

AFAICT there is a clear FESCo consensus that the list can not be exhaustive.

Essentially, asking for a promise to promote automatically if a
checklist is met is equivalent to asking for permission to promote
even if the software is known to be broken and/or unfixable.

There _are_ unknowns and risks in this process.  We can only shift the
place where they manifest, and asking for an exhaustive list
essentially shifts the risks to Fedora users and other Fedora
maintainers.  And again, the current discussions didn't suggest that
there is any communication breakdown between FESCo and the ARM team,
or that FESCo knows much more about ARM than the ARM team.  I don't at
all expect a situation in which the ARM team thinks everything is
working fine and FESCo doesn't.
    Mirek