Feedback on secondary architecute promotion requirements draft

[Matthew Garrett]

On Wed, Apr 18, 2012 at 07:04:24PM -0700, Brendan Conoboy wrote:
> 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'm confused. How would the Fedora experience be consistent across all 
primary architectures if an architecture community has no interest in 
supporting major parts of Fedora? Basically, I think the text already 
says this. I don't think adding examples make it clearer.

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

The kernel team may have their view skewed by how likely they think it 
is that a given architecture will be likely to force additional 
rebuilds. So yes, the point of this document is that it's architecture 
neutral, and so it's inappropriate for it to list figures that have been 
quoted for a specific architecture.

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

Not really. You could potentially satisfy number 8 without satisfying 
number 5, and you could satisfy number 5 without satisfying number 8.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org