launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

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

On 06/29/2010 09:32 PM, Martin Pool wrote:
> In bug 596796 Aaron says that he doesn't want to allow changing a
> prereq after an mp is created, because that "changes the meaning of
> the mp."  However, people are already able to change the meaning of an
> mp after it's created, by pushing new code into it.

Yes, but we can track that.  We track which revision of the branch was
approved, and in the future, we want to show the changes as diffs, too.

> I think the way that additional changes are shown in the history of an
> mp are one of the nicer parts: the overall proposal can evolve in
> response to feedback and you see the ongoing conversation.  I'd like
> to build on the success of that, both in how we show the changes and
> also perhaps by extending it to other things.

Changing branches is a much more serious change than adding revisions.
Changing the target branch can change the landing criteria.  Changing a
source branch (e.g. to continue stalled work) is something that someone
who doesn't own the merge proposal would want to do, and the owner might
disagree with.

Those situations should definitely be handled as a resubmit.
Prerequisite branch changes are not as strong a case, but having a
common strategy for changing any branch makes a lot of sense.

> If the principle is that mps are entirely immutable after they're
> created, why don't we disallow changing the code under review?

The principle is that we want to know what was reviewed, and what was
approved.  We track these things already.  Changing the prerequisite
branch changes the merge proposal in a way that adding new revisions
does not.

> At the moment it seems that "resubmit" means "wipe the slate clean",
> so that after a lot of changes we can start a new review.

No, it doesn't.  The comments and reviews from the previous proposal are
shown in the resubmitted one.  (But the votes are not included in the
totals, because they don't necessarily apply.)

In any case, I believe that "resubmit" is the correct way to handle
branch changes, so it makes sense to improve "resubmit" as part of this
work, so that it works well for users.

> New contributors tend to be confused about whether they should
> resubmit when they make a change.

If you're suggesting that the system is more complex than it needs to
be, I disagree.  If you mean there's a documentation problem, we can
probably fix that.

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

iEYEARECAAYFAkwuPZEACgkQ0F+nu1YWqI3xxwCfRPcKCv9/+XghdK7tlO7bJJ/i
M7kAn3XOtLL67Ff8FOzBaDLyZMCMwKB/
=EjpV
-----END PGP SIGNATURE-----