Feedback on secondary architecute promotion requirements draft

[Matthew Garrett]

On Thu, Apr 19, 2012 at 01:50:20AM -0400, Jon Masters wrote:
> * Not really sure how to word this, but something about the website,
> wiki, and documentation? After all, it's all very x86-ish right now.

You mean making sure that an architecture is covered by the 
documentation before promotion?

> * I'm trying to figure out what "adequate representation" means in the
> context of infrastructure and release engineering. For example, Dennis
> Gilmore is very involved in a number of secondary efforts and I would
> /think/ that would be sufficient? But are you putting specific head
> count requirements in terms of dedicated resources in here?

If the teams are happy with the level of coverage they have, that's 
going to be fine. This should just be a sanity check.

> * I would like clarification of "developer resources". For example, does
> this mean head count, hardware, both? And to what level? In terms of
> access to hardware, we're working on solutions for this. For those who
> work for Red Hat, I can get certain hardware made available internally
> (for e.g. ARM), and in the broader community, a certain amount of
> hardware is already being given out. But clearly, we can't give everyone
> one of every system. So having some numbers here - however vague they
> need to be - will help to clarify things. In the case of ARM, we'll
> endeavor to have certain hardware available in a central fashion that
> can be provisioned by individual developers (there are some technical
> challenges there, but that is being thought through).

If ARM regularly holds things up then the developer resources are 
inadequate. I don't think this is really something that can be 
quantified. Once you've aligned yourself with the primary architectures 
it ought to be pretty obvious whether promotion would cause problems - 
if you're getting packages fixed and built in a timely manner then we're 
good, if we're not then there's a problem.

> * Is the release criteria malleable when it comes to the influence of
> new architectures in general, in terms of what that might allow the
> distribution to do that it can't do on the existing architectures?

I'd guess there could be exceptions for sufficiently compelling cases. 
I'm not inclined to feel that ARM offers anything special enough to do 
so, but people could probably be convinced.

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