Open Stack

On 3 June 2015 at 07:12, John Griffith <john.griffith8 at gmail.com> wrote:

>
>
> On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand <iwienand at redhat.com> wrote:
>
>> On 06/03/2015 07:24 AM, Boris Pavlovic wrote:
>>
>>> Really it's hard to find cores that understand whole project, but
>>> it's quite simple to find people that can maintain subsystems of
>>> project.
>>>
>>
>>   We are made wise not by the recollection of our past, but by the
>>   responsibility for our future.
>>    - George Bernard Shaw
>>
>> Less authorities, mini-kingdoms and
>> turing-complete-rule-based-gerrit-subtree-git-commit-enforcement; more
>> empowerment of responsible developers and building trust.
>>
>> -i
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
> ​All of the debate about the technical feasibility, additional repos
> aside, the one question I always raise when topics like this come up is
> "how does that really solve the problem".  In other words, there's still a
> finite number of folks that dedicate the time to be "subject matter
> experts" and do the reviews.
>
> Maybe this will help, I don't know.  But I have the same argument as I
> made in my spec to remove drivers from Cinder altogether, creating "another
> repo" and moving things around just creates more overhead and does little
> to address the lack of review resources.
>

In the neutron project we do not have yet enough data points to assess
impact of driver/plugin split on review turnaround. On the one hand it
seems that there is no statistically significant improvement in review
times for the "core" part, but on the other hand average review times for
plugin/driver code have improved a lot. So I reckon that there's been a
clear advantage on this front. There is always a flip of the coin, of
course: plugin maintainers have to do extra work to chase changes in
openstack/neutron.

However, this is a bit out of scope for this thread. I'd say that splitting
out a project in several repositories is an option, but not always the
right one. In the case of neutron plugins and drivers, it made sense
because there is a stable-ish interface between the core system and the
plugin, and because there's usually little overlap of responsibilities.


> I understand you're not proposing new repos Boris, although it was
> mentioned in this thread.
>
> I do think that we could probably try and do something like growing the
> Lieutenant model that the Neutron team is hammering out.  Not sure... but
> seems like a good start; again assuming there are enough
> qualified/interested Lieutenants.  I'm not sure, but that's kind of how I
> interpreted your proposal but one additional step of ACL's; is that
> accurate?
>

While I cannot answer for Boris, my opinion is that the lieutenant system
actually tries to provide a "social" solution to the problem, where as ACLs
are a technical solution. I personally think that the belief that there's
always a tool to fix any problem is a giant unicorn - as Robert put it
there's no technical solution to a social problem. A technical solution
would probably end up bringing more process, more bureaucracy, and
therefore more annoyance... but I'm digressing.

In my opinion the lieutenant system is an attempt to build networks of
trusted and responsible developers who share interest (more or less vested)
and knowledge on a specific subsystem of a project. If implemented
correctly, it will ensure those networks are small enough so that trust can
be achieved in a simple way.
I'd rather rely on trust and common sense than on a set of ACLs that
probably at some point will get in the way and be more a hindrance than a
help.

Salvatore


>
> Thanks,
> John​
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150603/6ec69f18/attachment.html>