Poor support for merge proposals superseded by different branch
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
A relatively frequent occurrence in bzr's patch review process is this:
1. Alice proposes a patch
2. people review it, some changes are requested
3. Bob implements the changes.
Launchpad should allow Bob to mark Alice's proposal as Superseded by his, and have the review comments on Alice's proposal displayed as they would be if Alice has superseded her own proposal. (Bob may even choose to immediately set the new proposal as Approved or Queued, if he is confident all the review comments have been addressed safely.)
Instead, Bob has to deal with having two separate proposals active, or inaccurately mark Alice's original proposal as Approved, Rejected, or Work in Progress. Rejected is probably the least confusing, but is also the most rude.
This can happen because Alice doesn't have time to follow-up the original proposal quickly, or the patch pilot is simply trying to avoid roundtrips by implementing obviously good suggestions.
A related case is someone doing a rework of a rejected patch from someone else to take a different approach, but it is still based on the original branch, and the original review comments are still relevant.
An example that is current as I write this bug report is: <https:/
Changed in launchpad-code: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Bug #504369 discusses how we want to fix this.