support cherrypick merge proposals

[Robert Collins]

For Ubuntu packaging in bzr we want to be able to propose separate patches as separate merges without pre-requisite branches - as bzr cherrypicks.

[Martin Pool (mbp)]

We should basically remember -r X..Y parameters for the proposed merge?

--
Martin <http://launchpad.net/~mbp/>

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> For Ubuntu packaging in bzr we to be able to propose separate patches as
> separate merges without pre-requisite branches - as bzr cherrypicks.

I recommend performing the cherrypick into a branch and proposing *that*
for merge. The design of the code review system is that you propose a
branch for merge, and branches can be updated according to the review.

A cherrypick is a frozen thing. It goes against the grain of the code
review system.

Aaron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktsM9MACgkQ0F+nu1YWqI0yzACfefNzGVU24k6orQBuhrYAc/NO
uJ8An1AFi6MigQa3hCTRmNH2o29WSy5u
=R+a3
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

On 6 February 2010 02:05, Aaron Bentley <email address hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Robert Collins wrote:
>> For Ubuntu packaging in bzr we to be able to propose separate patches as
>> separate merges without pre-requisite branches - as bzr cherrypicks.
>
> I recommend performing the cherrypick into a branch and proposing *that*
> for merge.  The design of the code review system is that you propose a
> branch for merge, and branches can be updated according to the review.
>
> A cherrypick is a frozen thing.  It goes against the grain of the code
> review system.

That's a useful workaround and a true statement about the current
system but it's also kind of begging the question. (It is reasonable
to file bugs with use cases that suggest the current design is not
adequate to address user needs.)

We need to work out if Ubuntu actually specifically need to review
cherrypicks or if it will be easy for them to make specific branches
with the changes. If the second will work then it is a more natural
fit for both lp and bzr.

--
Martin <http://launchpad.net/~mbp/>

[Tim Penhey (thumper)]

Where is the evidence of this?

[Aaron Bentley (abentley)]

Martin, could you provide an example of how you would expect a system that accepted cherrypicks to work? What would happen when a reviewer said "You need to change X before I can approve this"? How could the implementer communicate the update to Launchpad? How would the diff be generated?

Basically, I think that my suggestion is not a workaround-- it is the right way to do it, because it provides a way for updates to make sense, and does not introduce complexity to the model. Do you have an alternative in mind that addresses this?

[Martin Pool (mbp)]

On 24 February 2010 01:17, Aaron Bentley <email address hidden> wrote:
> Martin, could you provide an example of how you would expect a system
> that accepted cherrypicks to work?  What would happen when a reviewer
> said "You need to change X before I can approve this"?  How could the
> implementer communicate the update to Launchpad?  How would the diff be
> generated?

Those are really good questions to which I have no easy answers. As I
said before

>> We need to work out if Ubuntu actually specifically need to review cherrypicks or if it will be easy for them to make specific branches with the changes. If the second will work then it is a more natural fit for both lp and bzr.

Until then, we can leave this incomplete.

--
Martin <http://launchpad.net/~mbp/>

[Francis J. Lacoste (flacoste)]

Marked as Invalid in Launchpad. Reopen when the UDD use case is settled.