[openstack-dev] The Evolution of core developer to maintainer?

Maru Newby marun at redhat.com
Wed Apr 1 19:00:53 UTC 2015

> On Apr 1, 2015, at 6:09 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> And here is the crux of the situation, which I think bears
> highlighting. These "empowered groups" are (or at least started out
> as) nothing more than an attempt to map responsibilities onto the
> ACLs available to our projects in the tools we use to do the work.
> Coming up with some new pie-in-the-sky model of leadership hierarchy
> is an interesting thought exercise, but many people in this
> discussion are losing sight of the fact that the model we have is
> determined to a great extent by the tools we use. Change the tools
> and you may change the model, but changing the model doesn't
> automatically change the tools to support it (and those proposing a
> new model need to pony up the resources to implement it in
> _reality_, not just in _thought_).

> Responsibilities not tied to specific controls in our tools do exist
> in abundance, but they tend to be more fluid and ad-hoc because in
> most cases there's been no need to wrap authorization/enforcement
> around them. What I worry is happening is that as a community we're
> enshrining the arbitrary constructs which we invented to be able to
> configure our tools sanely. I see this discussion as an attempt to
> recognize those other responsibilities as well, but worry that
> creation of additional unnecessary authorization/enforcement process
> will emerge as a "solution" and drive us further into pointless
> bureaucracy.

Given how important trust and relationships are to the
functioning of individual projects, I think we’re past the point
where we should allow our tooling to be the limiting factor in
how we structure ourselves.  Do we need finer-grained permissions
in gerrit to enable something like subtree maintainers?  I don't
believe we do.  In large projects like Neutron, there is no such
thing as someone who knows everything anymore, so we all need to
be aware of our limitations and know not to merge things we don't
understand without oversight from those of our peers that do.
Responsibility in this case could be subject to social rather than
tool-based oversight.


More information about the OpenStack-dev mailing list