Re: [Rdo-list] More transparency in RDO infra/process

2015-09-21 20:03 GMT+02:00 Rich Bowen <rbowen(a)redhat.com&gt;: Thanks Rich for bringing that topic and what follows will be my own PoV, not my employer's. First, until recently RDO had little to no external contributors, making opening the infrastructure and process a lower priority against making RDO a truly usable distro. Now, that RDO reached some maturity, openness is now on the top of the queue, a dedicated team (RDO Engineering) has been creating early 2015 to work full-time on RDO. RDO Engineering is one of the few team with Perry Myers organization that has *no* internal meeting/call, everything we do is in the *open*. Most of our decisions are discussed in this list or during our packaging meetings. I'd like to thank Alan (RDO Eng. team lead), Alvaro (RDO Eng, manager) and Perry (dept manager) to enforce that. And you Rich to ensure that RDO community grows healthily. Sorry for disclosing corporate secrets: any internal discussion concerning RDO ends up with someone reminding us that *NO, DON'T DO THAT, BRING THE DISCUSSION ON RDO LIST OR RDO PUBLIC CHANNEL!!!!* --- RDO Engineering has done a tremendous effort to open our infrastructure, our main build system is CentOS CBS (primarily maintained by alphacc from CERN!), anyone can submit packaging changes through gerrithub. All our tooling has been opened (delorean, rdopkg etc.), our trello is open, our bug tracker too. We're starting to see a RDO Team that is a superset of RDO Eng. made by non-redhatters, and redhatters from different teams or dept. At my level, I spend a significant amount of my time to mentor RDO contributors (and regardless of their affiliation). One of my goals is that most of the governance and effective stewardship of RDO belongs to the RDO Community becomes possible. We could create a governance body made up of non-redhatters but if they can't manage the infrastructure or enforce their decisions, it would be shallow. ----- Is that enough? the answer is NO We need to define our processes, so that people won't get confused and lower as much as possible the entry barrier. Our current infrastructure is still a patchwork: * builders are scattered between Fedora Koji, CBS, copr * no single accounting/access control system * lack of automation * CI has yet to be opened. => That makes it to hard to grant access to external contributors as we don't have control over our infrastructure. And we can't grant finer-grained accesses, which does not help in granting more people access to our infrastructure. Especially when CI and more generally infrastructure is not reliable and we're missing a lot of safety checks. We've been working into consolidating our infrastructure (Cf. the fedora thread), and have a dedicated person to work full-time on RDO CI so we could open it. it'll get better. As our platform will be stabilizing, we'll be able to welcome more contributors and grant them more access. Even myself don't have access to everything and sometimes, it's frustrating not being able to fix trivial things. As someone who saw Fedora's evolution over the years, and who co-founded CentOS Cloud SIG, it takes time to build a truly open community. Currently RDO is not that much different from early Fedora Core. We have yet to build our infra and define our processes but we're on the path to be a fully open community. Our priority is to stabilize our foundations (including infrastructure), strive to lower the contribution barrier, keep the decision process transparent and open. Regards, H. PS: I like having my team meeting on a public irc channel, and that I don't need connecting corporate VPN to do my main job, that my team is not limited to Red Hat folks, don't take that away from me!