openstack team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Ed Leafe
> Sent: 03 February 2011 14:18
> To: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure blueprint
> 
> On Feb 3, 2011, at 8:52 AM, Jay Pipes wrote:
> 
> >> Absolutely not, as long as we're not trying to merge conflicting
> branches.  That was the problem last time -- I18N and the logging
> changes in particular were such pervasive pieces of work that it was
> hard work merging all the time.  Hopefully we won't see the likes of
> those again for a little while!
> >
> > Hehe, understood. I did 6 or 7 merge trunks while dealing with i18n,
> > so I feel you :)  But, luckily, we don't look to have any of those
> > super-invasive blueprints on deck for Cactus...but you never know ;)
> 
> 
> 	Is there any proscription about merging a partial change? IOW, if
> something like the logging change affected 100 files, would it be
> acceptable to merge, say, 20 at a time? As long as tests continue to
> pass, of course, and the merge prop is labeled as a partial
> implementation, and everything else continues to work without problem.
> This way any individual merge will only conflict with a few branches,
> while huge mega-merges will conflict with just about everything.

I'd much rather do small merges.  I'm a "commit-once, commit-often" man, for exactly this reason.

I think the objection was that it would be difficult to peer-review stuff if it was coming in piecemeal, because you don't get to see the big picture of the change.  That's a reasonable comment, and commit-once, commit-often does rely on the fact that you trust the person making all those commits.

Maybe we should normally do big-picture merges normally, but have an exception procedure for when we'd like them piecemeal.

Ewan.