Open Stack

Joe Gordon wrote:
>
>
> On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez <thierry at openstack.org
> <mailto:thierry at openstack.org>> wrote:
>
>     Joe Gordon wrote:
>     > >     My main objection to the model you propose is its binary
>     nature. You
>     > >     bundle "core reviewing" duties with "drivers" duties into a
>     single
>     > >     group. That simplification means that drivers have to be core
>     reviewers,
>     > >     and that core reviewers have to be drivers. Sure, a lot of core
>     > >     reviewers are good candidates to become drivers. But I think
>     bundling
>     > >     the two concepts excludes a lot of interesting people from
>     being a
>     > > "driver".
>     >
>     >  I cannot speak for all projects, but at least in Nova you have to be a
>     >  nova-core to be part of nova-drivers.
>
>     And would you describe that as a good thing ? If John Garbutt is so deep
>     into release liaison work that he can't sustain a review rate suitable
>     to remain a core reviewer, would you have him removed from the
>     "maintainers" group ? If someone steps up and works full-time on
>     triaging bugs in Nova (and can't commit to do enough reviews as a
>     result), would you exclude that person from your "maintainers" group ?
>
>
> I want to empower that person and recognize them in some semi formal
> capacity and make sure they have all the correct permissions.
>
> I do not want a single flat 'maintainers' group, I think we need a
> hierarchical notion of maintainers, where different people can end up
> with very different responsibilities (and ACLs -- but that is a
> implementation detail).
>
>
>     > >     If someone steps up and owns bug triaging in a project, that
>     is very
>     > >     interesting and I'd like that person to be part of the
>     "drivers" group.
>     >
>     >  In our current model, not sure why they would need to be part of
>     >  drivers. the bug triage group is open to anyone.
>
>     I think we are talking past each other. I'm not saying bug triagers have
>
>
> It appears that we are talking past each other, at least we agree on
> something.
>
>     to be drivers. I'm saying bug triagers should be *allowed* to
>     potentially become drivers, even if they aren't core reviewers. That is
>     including of all forms of project leadership.
>
>     You are the one suggesting that maintainers and core reviewers are the
>     same thing, and therefore asking that all maintainers/drivers have to be
>     core reviewers, actively excluding non-reviewers from that project
>     leadership class.
>
>     > >     Saying core reviewers and maintainers are the same thing, you
>     basically
>     > >     exclude people from stepping up to the project leadership
>     unless they
>     > >     are code reviewers. I think that's a bad thing. We need more
>     people
>     > >     volunteering to own bug triaging and liaison work, not less.
>     >
>     >  I don't agree with this statement, I am not saying reviewing and
>     >  maintenance need to be tightly coupled.
>
>     You've been proposing to rename "core reviewers" to "maintainers". I'm
>     not sure how that can be more tightly coupled...
>
>
> All core reviewers in our current model should be responsible for
> maintenance of the project, but not all maintainers need to be
> responsible for reviewing code anywhere in the project.
>
>
>      > [...]
>     >  I really want to know what you meant be 'no aristocracy' and the why
>     >  behind that.
>
>     Aristocracies are self-selecting, privileged groups. Aristocracies
>     require that current group members agree on any new member addition,
>     basically limiting the associated privilege to a caste. Aristocracies
>     result in limited gene pool, tunnel vision and echo chamber effects.
>
>     OpenStack governance mandates that core developers are ultimately the
>     PTL's choice. Since the PTL is regularly elected by all contributors,
>     that prevents aristocracy.
>
>
> Can you site your source for this? Because the earliest reference to
> 'Core Developer' (what you are calling core reviewer -- even though that
> is not the original name) that I could find says nothing about it
> ultimately being the PTLs choice.
>
> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
> Where is the current documentation on this?
>
>
>     However in some projects, core reviewers have to be approved by existing
>     core reviewers. That is an aristocracy. In those projects, if you
>
>
> Which projects do it differently?
>
> So this is where you loose me. Has there ever been a case of a project's
> PTL adding/removing people from the core team where the PTL goes against
> the majority of the core developers?  You say that an early (unwritten?)
> goal of the system we have is to prevent 'aristocracy,' but all I see is
> 'aristocracy'.
>
> It sounds like if a goal was no aristocracy then we have miserably
> failed at that. But frankly I don't know to prevent what you call
> aristocracy.
>
>     associate more rights and badges to core reviewing (like by renaming it
>     "maintainer" and bundle "driver" responsibilities with it), I think you
>     actually extend the aristocracy problem rather than reduce it.
>
>
> So, let me take a step back here. I would like to see at least 2 to 3x
> more people in a given project to feel empowered and have badges, and
> make it possible for part time upstream developers to hold some of said
> badges.  It sounds like you more or less agree with that goal. So how do
> you propose we get there?
>
> Because having 15 core reviewers for all of nova is just not cutting it.

Add them all, guide them, teach them... profit...

In general I feel people(s) are to do good; and it'd be nice to break 
down some of these artificial barriers and let people behave as people 
(and help nova/others...).

>
>
>     --
>     Thierry Carrez (ttx)
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev