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

[Haïkel]

2015-09-21 20:03 GMT+02:00 Rich Bowen <rbowen at redhat.com>:
> I wanted to share a portion of a conversation with folks here, and ask for
> some help.
>
> To summarize, it's confusing to people who are not part of the process (and
> often for people who are) where all of the pieces of the RDO process live,
> what they do, how they talk to one another, and so on. Because of how RDO
> has evolved, and interacted with other parties (Fedora, CentOS, upstream
> OpenStack, Trystack, and now the rpm-packaging upstream project, and
> probably other things I'm forgetting) it can feel, sometimes, that there's
> some magic involved.
>
> I'd like to bring more clarity to this with some docs, some diagrams, and
> whatever else we need to do, both to bring more transparency to the process,
> and to help people who are trying to get involved, find their way. I could
> definitely use your help in making that happen.
>
> --Rich
>

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!

>
> -------- Forwarded Message --------
> On 09/18/2015 05:49 AM, Rich Bowen wrote:
>>
>>
>>
>>>>> * One of the criticisms against RDO at the moment is the lack of real
>>>>> transparency and confusion as to the infrastructure and systems that
>>>>> power it.
>>
>>
>>
>> I'm curious where you're seeing this criticism, as I haven't seen it at
>> all. I'll take this as an action item to thoroughly document the
>> infrastructure and systems that power RDO, but I was completely unaware
>> that this was a concern.
>>
>>
>>
>
> It's been mentioned to me by operators that I've spoken to at Meetups
> and the like. It's more of a casual observation from users who are more
> interested in contributing and being a part of RDO.
>
> If you look at Fedora as an example, all the infrastructure is exposed,
> they have things like bohdi and koji that allow you to directly see and
> "touch" the entire process used to ship Fedora. You can very easily
> follow the process code goes through the whole system to get out the
> door (and the documentation of how it all works is very good).
>
> While all the pieces of RDO are open (I think), there is no unified
> documentation that shows you a birds eye view of how it all works. We
> have tools like delorean and rdopkg which aim to make things easier for
> people (and they do), and you often follow the documentation to do what
> you need to do, without understanding why. How does code upstream get
> into RDO? Following the packging docs it looks like it touches github,
> fedora, delorean, and other pieces.
>
> Things like Delorean and the CI parts often have no links off the main
> rdo website (or if they do, they are buried in a page somewhere). We
> have pieces running on OS1, we have pieces running on Trystack, we have
> pieces living inside fedorapeople (?), we have pieces in Centos/CBS, I'm
> still not entirely sure where the main site itself is running so if
> anyone wants to actually try and understand the infrastructure (and in
> particular, what infrastructure impacts RDO) it's a mystery.
>
> Even something as simple as this
>
> https://apps.fedoraproject.org/
>
> To have links to all the parts of the RDO that exist currently, would be
> a massive help.
>
> <snip>
>
> Note Rich this is not a slight against yourself and the fantastic work
> you have done for RDO, I think this is more because the RDO project has
> had to grow, change and adapt so quickly, everything is moving at
> breakneck speed so it's hard for people not involved to keep up.
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com