launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

https://bugs.launchpad.net/bugs/596796
https://bugs.edge.launchpad.net/launchpad-code/+bug/596796 and
https://bugs.edge.launchpad.net/launchpad-code/+bug/504369 seem to me
to show some conflict at the user model level about what kind of
changes are allowed in merge proposals after they're created.

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.

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.

If the principle is that mps are entirely immutable after they're
created, why don't we disallow changing the code under review?  But
doing so would be a big step backwards in usability.

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.  If it has
that semantic meaning it would be unfortunate to require people to
resubmit just because they made a mistake in creating the proposal.

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

-- 
Martin