continuing anothers work - launchpad merge proposals, mail spam

John Arbash Meinel john at arbash-meinel.com
Tue Jun 22 16:27:40 BST 2010


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

Martin Pool wrote:
> On 22 June 2010 15:09, Andrew Bennetts <andrew.bennetts at canonical.com> wrote:
>> Robert Collins wrote:
>> [...]
>>> I don't want to stress or annoy folk though, and I think it might at
>>> the moment. We can address part of it, I think, by using a
>>> prerequisite branch of the existing MP; this is a bit of a hack, when
> 
> I do think that if the new branch includes only small additional
> changes doing this generates a lot of noise.
> 
> It is a bit weird to be asked to review something that looks 95% the
> same as my own patch from last week, and to not be sure if I'm
> supposed to actually review it, or whether the mp is just a formality
> as it's queued for pqm.

I think this is a case where using the prerequisite feature is reasonable.

I do think that *our* workflow (and possibly LP by extension) should
have a way to a contributed patch, work on it, and have a reasonable way
to provide the updates for review. Especially with Patch Pilot, we want
a way to say "I like what you've done, but it needs tests, here are
those tests." At the moment, we tend to do this a bit out of band. Say
by doing the work, and then telling the person as a comment that we have
a branch over here that they might want to merge into their own. Or by
just doing it manually and using pqm-submit.

And the last I read, I thought there was a push was to completely stop
using 'pqm-submit' and instead only go through the review queue +
feed-pqm sort of stuff. Certainly Robert seems to be doing that. (I may
be wrong about things that he landed but considered 'trivial'.)


> 
>> I think this is a decent workaround until LP has better support for this
>> situation.
>>
>> We should be explicit about what to do with the prerequisite branch (the
>> pseudo-superseded one) at the same time.  I suggest marking it Work In
>> Progress while leaving a comment saying it's actually been superseded by
>> the MP at $URL.  That way the review queue is not cluttered by it, and
>> any humans looking at it will be able to figure out what's really going
>> on.
> 
> I guess it's not yet possible to mark the earlier branch superseded by
> the later one?  If not, this is ok.
> 
> If you're effectively superseding someone else's patch it will avoid
> confusion to make a comment as spiv says and also to say in the new
> one whether you're planning to feed it in right away, or to ask for
> additional review, or something else.  Another option is to manually
> attach an incremental diff to the later mp.

Even if LP supported a pure "my branch supersedes this branch", you
would still get the full (non-incremental) diff. (You get the full diff
today if you just resubmit your proposal.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwg1mwACgkQJdeBCYSNAAPCegCgyEU4nbryf5OzCBNbQjXCip9U
r40AnRUCJMoDAbKlHgoHn61RFA2MhyEs
=8HG3
-----END PGP SIGNATURE-----



More information about the bazaar mailing list