Feedback on secondary architecute promotion requirements draft

[Brendan Conoboy]

On 04/04/2012 03:26 PM, Matthew Garrett wrote:
>> 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.

Just hardware, or hardware and software?  Or hardware, software, and 
community?  If hardware is capable of providing a desktop experience, 
but only with proprietary drivers, does that mean the arch isn't 
acceptable as PA?  What if some forms of the hardware are desktop 
capable, others are not, but the community only has an interest in 
supporting headless installations?  I think we're all going to be 
rational about this, but my rational and yours might not match up.

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

If that's the case please spell it out:

SA must secure from the Fedora Infrastructure and Release Engineering 
teams a statement that they are prepared to support the SA as PA.  It us 
up to these teams how to form that consensus and provide an answer.  The 
question should be formally posed to their respective mailing lists 
unless they have an otherwise stated policy.

Or something like that.

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

Okay- would you put that in the document?

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

I believe a subsequent discussion on the matter has yielded the value of 
4 hours.  Can the guidelines include this, perhaps with the caveat of 
"At the time this draft was approved, the agreed maximum build time for 
a kernel was 4 hours."

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

Okay, you're clearly writing that with a do everything to be PA while 
SA, then you'll have proved yourself mindset.  That's fine, but it would 
help to spell this out.  You might just as well say all 
architecture-specific issues are fixed before promotion may be granted. 
  I'm not sure that's an achievable goal, frankly, but that does seem to 
be what you're saying.

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

Would like to see clarification on whether using a simulator (with X 
support) would meet this requirement.  If not then the requirement is 
essentially: Most packagers on the critical path must own one of these 
SA-supported systems before it can be primary.

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

Okay, please clarify in the document.

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