Joe Gordon wrote:
On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez <[email protected]
<mailto:[email protected]>> 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:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
