Feedback on secondary architecute promotion requirements draft

[Peter Robinson]

2012/4/3 Miloslav Trmač <mitr at volny.cz>:
> 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.

It's already been stated that 3D isn't a blocker for PA, but that the
needs to be reasonable GUI support similar to that of the mainline
project.

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

Yes.

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

As long as it's reasonable, if it's too strict on primary at the
moment that is a completely separate discussion and not really related
to this one and is likely very much a matter of opinion :)

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

I agree it's hard to make it exhaustive but ultimately it can't be a
moving target with extra items added and the goal posts moved every
time it's reached.

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

We're not asking for that what so ever. What we're asking for is a pre
decided and agreed point we need to reach that doesn't keep on moving.
Ultimately there's a lot of packages that are broken on x86 mainline
at the moment (just look at the list of FTBFS that still exist from
the gcc 4.7 mass rebuild) so we're not asking for instant promotion if
stuff is known to be broken, it's never been bought up so I'm not sure
where you get that idea from.

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

Of course there are unknown risks, there's also unknown risks every
time a core package is bumped, or each time infra/rel-eng change
something, but there's benefits to those changes as well. Just like
that there are unknown risks and possible issues with promotion of a
new architecture but there are also known benefits which is ultimately
why we've asked FESCo to create these criteria, different people put
different benefits to the criteria but ultimately personally I believe
it will be a net gain for Fedora.

Peter