Why a merge proposal for merge 2.2 to trunk? Re: [Merge] lp:~spiv/bzr/merge-2.2-into-trunk into lp:bzr

[Andrew Bennetts]

John A Meinel wrote:
[...]
> Merge up from 2.x to 2.x+1 or trunk is always allowed. Is there
> something about this that you specifically want reviewed? (Some conflict
> resolution that was particularly hairy, etc?)
> 
> I certainly don't want to re-review 5000 lines of already approved 2.2
> changes, but I'm happy to look at anything specific you want.

There were a couple of reasons for creating this merge proposal, in no
particular order:

 * I'm trying to use 'feed-pqm' rather than 'bzr pqm-submit' for all my merges,
   because that seems to be the preferred way (and more so in future as merge
   queue management is taken over by Launchpad).  So I needed a merge proposal.
 * It was an unusually hairy merge, so I wanted to make a little bit of noise
   about it so that if I did screw something up (and thus cause a regression in
   trunk) it other people would have a clue about what happened.
 * In an ideal world, it would be possible to review how I resolved the merge
   without reading 5000 lines of bits I didn't touch.  If making that merge
   proposal prompted someone to figure out how to make that happen, great ;)
 * I was a bit surprised to have such an involved set of conflicts to resolve in
   the first place, and thought making that fact a little more visible wouldn't
   hurt.  We apparently had a let a fair bit of divergence occur, and had some
   criss-crosses.
 * I was rapidly running out of time at end of my work week, so wanted someone
   else to land it and hopefully deal with trivial landing failures (NEWS
   conflicts or whatever) if any happened, rather than letting the branch go
   stale during the 4-day weekend I had planned.

None of those reasons were particularly compelling on their own, but the
combination made me think “ah what the heck, just fire off a merge proposal.”

-Andrew.