On Wed, 2016-07-20 at 11:58 +0200, Julien Danjou wrote: > On Tue, Jul 19 2016, Clint Byrum wrote: > > > Perhaps if we form and start working together as a group, we can > > disect why nothing happened, build consensus on the most important > > thing to do next, and actually fix some architectural problems.
Architecture is often blamed for lack of interlock but most people forget that the need for interlock often isn't appreciated until after the components are built. This is why a lot of people embrace agile methodology (an excuse for not seeing the problem a priori). Conversely, architects who try to foresee all interlocks often end up with a combinatorial explosion that makes it a huge burden simply to begin the project (and then often get sidelined as 'powerpoint engineers'). The trick is to do something in the middle: try to foresee and build the most common interlocks, but sidestep the combinatorial explosion by building something simple enough to adapt to any interlock requirement that arises after completion. > > The social structure that teams have is a huge part of the > > deadlock we find ourselves in with certain controversial changes. > > The idea is to unroll the dependency loop and start _somewhere_ > > rather than where a lot of these efforts die: starting > > _everywhere_. > > I agree with your analysis, but I fail to see how e.g. a group of > people X stating that Y should work this way in Cinder is going to > achieve any change if nobody from Cinder is in X from the beginning. > > This is basically what seems to happen in many [working] groups as > far as I can see. So this is where the Open Source method takes over. Change is produced by those people who most care about it because they're invested. To take your Cinder example, you're unlikely to find them within Cinder because any project has inertia that resists change. It takes the energy of the outside group X to force the change to Y, but this means that X often gets to propose, develop and even code Y. Essentially they become drive by coders for Cinder. This is where Open Source differs from Enterprise because you have the code and the access, you can do this. However, you have to remember the inertia problem and build what you're trying to do as incrementally as possible: the larger the change, the bigger the resistance to it. It's also a good test of the value of the change: if group X can't really be bothered to code it (and Cinder doesn't want it) then perhaps there's not really enough value in it anyway and it shouldn't happen. This latter observation is also an improvement over the enterprise methods because enterprise architects do often mandate interlocks that later turn out to be unnecessary (or at least of a lot less value than was initially thought). I suppose the executive summary of the above is that I don't think you're describing a bug, I think you're describing a feature. James
signature.asc
Description: This is a digitally signed message part
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
