openstack team mailing list archive

[Ed Leafe <ed@xxxxxxxxx>]

On Dec 23, 2010, at 3:15 AM, Thierry Carrez wrote:

> On the plus side, this technique allows simpler reviews and reduces the
> risks of conflict, so it probably ends up being faster. On the minus
> side, it's hard to functionally review or test something that is not
> complete, so the load on reviewers is, I think, higher.
> 
> Do we have a position on that ? Is it encouraged, discouraged, or nobody
> cares either way ?


	My take on this is that some blueprints, such as this one, are too broad in scope to reduce to a single merge. If a large change can be broken down into a smaller set of steps, and each step can be merged without breaking anything else, then I think that incremental merges make the process easier to manage, not more difficult. Big huge merges of wide-ranging changes smells too much like waterfall for my tastes.

	One caveat is that this requires a little more explanation in the commit messages, so that everyone knows what the intention of the commit is. Josh did that on the blueprint whiteboard, but not in the commit message for the merge proposal. Since that message becomes the part of the bzr log, it should be much more detailed: what the overall goal is; what this merge represents, and what the next phase of development will be.



-- Ed Leafe