Open Stack

Josh,

Yep let's just make experiment in Rally and I will share experience with
the rest of community.

Best regards,
Boris Pavlovic

On Wed, Jun 3, 2015 at 9:45 PM, Joshua Harlow <harlowja at outlook.com> wrote:

> Soooo, just some thoughts,
>
> If boris thinks this might help rally, why not just let him try it?
>
> If boris (and friends) will make the needed changes to jenkins or other to
> have whatever ACL format (avoid a turing complete language please) that
> says who can work in what directories in the rally repo then meh, why is
> this such a big deal? If it ends up not working out, oh well, if it ends up
> being a trust issue in the end, oh well, live and learn right?
>
> IMHO let boris try it, if it works out as a model for rally, more power to
> him, if it doesn't, well that's how people learn, and it can then be
> something that didn't work for rally. Everyone will move on, people will
> have learned what didn't work, and life will go on...
>
> It starts to feel that we have each a different model that we know and may
> not want to just let another model (that may or may not work well for
> rally) in. If we lived like that we'd probably all still be on horses and
> still think the world is flat and that the universe revolves around the
> earth.
>
> -Josh
>
> Boris Pavlovic wrote:
>
>> James B.
>>
>> One more time.
>> Everybody makes mistakes and it's perfectly OK.
>> I don't want to punish anybody and my goal is to make system
>> that catch most of them (human mistakes) no matter how it is complicated.
>>
>> Best regards,
>> Boris Pavlovic
>>
>>
>> On Wed, Jun 3, 2015 at 5:33 PM, James Bottomley
>> <James.Bottomley at hansenpartnership.com
>> <mailto:James.Bottomley at hansenpartnership.com>> wrote:
>>
>>     On Wed, 2015-06-03 at 09:29 +0300, Boris Pavlovic wrote:
>>      > *- 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.
>>
>>     This is completely antithetical to the open source model.  You have to
>>     trust people, that's why the project has hierarchies filled with more
>>     trusted people.  Do we trust people never to make mistakes?  Of course
>>     not; everyone's human, that's why there are cross checks.  It's simply
>>     not possible to design a system where all the possible human mistakes
>>     are eliminated by rules (well, it's not possible to imagine: brave new
>>     world and 1984 try looking at something like this, but it's impossible
>>     to build currently in practise).
>>
>>     So, before we build complex checking systems, the correct question to
>>     ask is: what's the worst that could happen if we didn't?  In this
>> case,
>>     two or more of your lieutenants accidentally approve a patch not in
>>     their area and no-one spots it before it gets into the build.
>>     Presumably, even though it's not supposed to be their areas, they
>>     reviewed the patch and found it OK.  Assuming the build isn't broken,
>>     everything proceeds as normal.  Even if there was some subtle bug in
>> the
>>     code that perhaps some more experienced person would spot, eventually
>> it
>>     gets found and fixed.
>>
>>     You see the point?  This is roughly equivalent to what would happen
>>     today if a core made a mistake in a review ... it's a normal
>> consequence
>>     we expect to handle.  If it happened deliberately then the bad
>>     Lieutenant eventually gets found and ejected (in the same way a bad
>> core
>>     would).  The bottom line is there's no point building a complex
>>     permission system when it wouldn't really improve anything and it
>> would
>>     get in the way of flexibility.
>>
>>     James
>>
>>
>>
>> __________________________________________________________________________
>> 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/f74e70a5/attachment-0001.html>