Feedback on secondary architecute promotion requirements draft

[Jon Masters]

Hey guys,

Cutting this sub-thread off at the pass :)

I think it's obvious that we in the ARM project can do a better job at
engagement, cohesion, and we can learn and improve in many ways. I would
like to suggest that we steer this thread back toward the more abstract
question at hand: that of secondary promotion criteria. With that in
mind, I've a few thoughts specific to the existing draft, some of which
have been touched on already, but let me just offer my $0.02:

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

* 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?

* We agree on the need for Fedora maintained servers. Absolutely. We'll
drop the notion of interim solutions (for any architecture).

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

* 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?

Thanks for reading. Meanwhile, we genuinely will take the earlier
comments on board about a need to improve our level of engagement.

Jon.