Open Stack

On 04/01/2015 05:41 AM, Thierry Carrez wrote:
> Joe Gordon wrote:
>> I am starting this thread based on Thierry's feedback on [0].  Instead
>> of writing the same thing twice, you can look at the rendered html from
>> that patch [1]. Neutron tried to go from core to maintainer but after
>> input from the TC and others, they are keeping the term 'core' but are
>> clarifying what it means to be a neutron core [2]. [2] does a very good
>> job of showing how what it means to be core is evolving.  From 
>>
>>     "everyone is a dev and everyone is a reviewer. No committers or repo
>>     owners, no aristocracy. Some people just commit to do a lot of
>>     reviewing and keep current with the code, and have votes that matter
>>     more (+2)." (Theirry) 
>>
>> To a system where cores are more then people who have votes that matter
>> more. Neutron's proposal tries to align that document with what is
>> already happening.
>>
>>     1. They share responsibility in the project's success.
>>     2. They have made a long-term, recurring time investment to improve
>>     the project.
>>     3. They spend their time doing what needs to be done to ensure the
>>     projects success, not necessarily what is the most interesting or fun.
> 
> A bit of history is useful here.
> 
> We used[1] to have 4 groups for each project, mostly driven by the need
> to put people in ACL groups. The PTL (which has ultimate control), the
> Drivers (the trusted group around the PTL which had control over
> blueprint targeting in Launchpad), the Core reviewers (which have +2 on
> the repos in Gerrit), and the bug team (which had special Launchpad bugs
> rights like the ability to confirm stuff).
> 
> [1] https://wiki.openstack.org/wiki/Launchpad_Teams_and_Gerrit_Groups
> 
> In that model, "drivers" is closer to what you describe for
> "maintainers" -- people invested 100% in the project success, and able
> to spend 95% of the work time to ensure it.
> 
> 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".
> 
> 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.
> That said, bug triaging (like core reviewing) is a full time job. You
> can't expect the person who owns bug triaging to commit to the level of
> reviewing that core reviewers commit to. It's also a different skillset.
> 
> 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.
> 
> So, in summary:
> 
> * I'm not against reviving the concept of drivers
> * I'm against making core reviewing a requirement for drivers
> * I'm for recognizing other duties (like bug triaging or liaison work)
> as being key project leadership positions

++