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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
