launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 3 July 2010 05:27, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----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.

If you want to be strict, or if this mp is a mode where it wants to be
strict, you could track which versions of the dependencies were
approved.  Or you could do something like the chained locks I
mentioned in the other mail.  Preventing people adding a dependency
doesn't in itself help.

>> 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.

That's an understandable rule, I think: you can't change the branches
involved in an mp after it was created.  It means that a couple of use
cases from Tim's list need some love: I made a mistake creating the
mp, and I discover during the course of discussion that part of it
should be split into a different branch.

Even if these are different mps there will still be a single
conceptual review thread going across all of them and people will want
to see its history.

>> 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.

It's more of just an observation: people do in fact get confused about this.

I don't think just adding help text will be a very good solution, but
I don't think the conceptual model needs to be tossed out either.
Perhaps working through the use cases in Tim's post will make it more
clear where the snags are and they can be fixed in the ui.

-- 
Martin