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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
