On 20 July 2016 at 19:57, James Bottomley < james.bottom...@hansenpartnership.com> wrote:
> > OK, I accept your analogy, even though I would view currency as the > will to create and push patches. > > The problem you describe: getting the recipients to listen and accept > your patches, is also a common one. The first essential is simple > minimal patches because they're hard to reject. > > Once you've overcome the reject barrier, there's the indifference one > (no-one says no, but no-one says yes). > > [snip] The trouble with drive-by architecture patches (or large feature patches of any kind) is that it is often better *not* to merge them if you don't think the contributor is going to stick around for a while. This changes are usually intrusive, and have repercussions that take time to discover. It's often difficult to keep a change clean when the original author isn't around to review the follow-on work.
__________________________________________________________________________ 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