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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
