Open Stack

Guys,

I will try to summarize all questions and reply on them:

*- Why not splitting repo/plugins?*

  I don't want to make "architectural" decisions based on "social" or
  "not enough good tool for review" issues.

  If we take a look at OpenStack that was splited many times: Glance,
Cinder, ...
  we will see that there is a log of code duplication that can't be removed
even after
  two or even more years of oslo effort. As well it produce such issues
like syncing
  requirements, requirements in such large bash script like devstack,
  there is not std installator, it's quite hard to manage and test it and
so on..

  That's why I don't think that splitting repo is good "architecture"
decision - it makes
   simple things complicated...


*- Why not just trust people*

People get tired and make mistakes (very often).
That's why we have blocking CI system that checks patches,
That's why we have rule 2 cores / review (sometimes even 3,4,5...)...

In ideal work Lieutenants model will work out of the box. In real life all
checks like:
person X today has permission to do Y operation should be checked
automatically.

This is exactly what I am proposing.

Best regards,
Boris Pavlovic

On Wed, Jun 3, 2015 at 8:42 AM, Salvatore Orlando <sorlando at nicira.com>
wrote:

>
>
> 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
>>
>>
>
> __________________________________________________________________________
> 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/e2319abc/attachment.html>