On 24 November 2015 at 06:21, Adam Young <[email protected]> wrote: > > So, having been one of the initial architects of said policy, I'd like to > reiterate what I felt at the time. The policy is in place as much to > protect the individual contributors as the project. If I was put in a > position where I had to review and approve a coworkers code changes, it is > is easier for me to push back on a belligerent manager to say "this > violates project policy." > > But, even this is a more paranoid rationale than I feel now. Each of us > has a perspective based on our customer base. People make decisions based > on what they feel to be right, but right for a public cloud provider and > right for an Enterprise Software vendor will be different. Getting a > change reviewed by someone outside your organization is for perspective. > Treat it as a brake against group think. > >
I don't think cinder has ever formalised on this policy, and I don't necessarily think it should, but having it there as strong guidance is definitely useful in order to push back against internal management pressure when needed. It isn't a matter of trust, or even group think (though that can definitely be a problem) but one of giving developers (iin this case cores) the tools they need to push back against pressure inside their own companies. In a similar vein, many well meaning and hard working engineers hit massive problems trying to get resources for CI until we started removing drivers from tree. Companies, particularly big ones, are slow moving, difficult to steer behemoths at times, and giving cores the tools to protect themselves, or devs more tools to help them get their job done, is definitely something we need to keep in mind. Personally, my biggest indicator of a 'forced' review is time - if something has been open for two weeks with zero negative feedback, on an uncontentious topic, then I really don't care too much who approves it. If something lands in four hours during the European night on a topic that has been bounced around a lot on IRC/email then I get more worried, regardless of the organisation(s) of the cores who merged it. No amount of rules will fix that though, only discussion and trust of cores. Giving them a rule to stand behind when saying 'no' to their management chain is a great help though. -- Duncan Thomas
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
