Feedback on secondary architecute promotion requirements draft

[Brendan Conoboy]

On 04/18/2012 06:42 PM, Matthew Garrett wrote:
[snip]
>> What if some forms of the hardware are desktop capable, others are
>> not, but the community only has an interest in supporting headless
>> installations?
>
> Then it's not fit to be a primary architecture.

Okay, please add examples like this wherever possible.

>> 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."
>
> No, because it's the kind of thing that's going to be influenced by
> multiple factors. Each architecture seeking PA status should have this
> discussion with the kernel team.

Huh?  The whole point of this item is that it's architecture neutral- 
the kernel team for security reasons believes it important that all 
kernel builds take less than 4 hours from start to finish.  Why would a 
new architecture change that number?  There's a caveat in the suggested 
wording above.  Don't understand the resistance.

>> 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.
>
> Becoming a PA won't magically produce extra maintainers. It's still
> going to be up to the architecture maintainers to deal with ARM-specific
> bugs in packages, if the package maintainer isn't able to deal with
> them. So, yes, I think in this respect it's important for the SA to
> demonstrate that it's not going to hold up development once it becomes
> primary.

I'm nonplussed by the answer, but can't disagree with it either.  This 
seems to make #5 and #8 the same thing.  You just need to merge them by 
adding the changes you'd already agreed with below, and including 
something like "All packages that are architecture neutral or have been 
ported to ARM must build from the same srpm prior to PA promotion."

[snip]
>>> 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.
>
> Ok.

Thanks!

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