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 <harlo...@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.bottom...@hansenpartnership.com >> <mailto:james.bottom...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev