Merge lp:~abentley/bzr/lpsubmit into lp:bzr
| Status: | Merged |
|---|---|
| Approved by: | Martin Pool on 2010-02-17 |
| Approved revision: | not available |
| Merged at revision: | not available |
| Proposed branch: | lp:~abentley/bzr/lpsubmit |
| Merge into: | lp:bzr |
| Diff against target: |
496 lines (+427/-2) 4 files modified
NEWS (+3/-0) bzrlib/plugins/launchpad/__init__.py (+71/-2) bzrlib/plugins/launchpad/lp_api.py (+147/-0) bzrlib/plugins/launchpad/lp_propose.py (+206/-0) |
| To merge this branch: | bzr merge lp:~abentley/bzr/lpsubmit |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Martin Pool | Needs Fixing on 2010-02-17 | ||
| John A Meinel | 2010-02-08 | Approve on 2010-02-09 | |
|
Review via email:
|
|||
Commit Message
Add lp-submit command.
| Aaron Bentley (abentley) wrote : | # |
| John A Meinel (jameinel) wrote : | # |
I didn't focus too concretely on this, since it is part of the Launchpad plugin. (So the review and coding standards are looser than for bzrlib code.)
Some comments
1) There doesn't seem to be a way to supply the initial merge comment from the command line, as '-m' sets the commit message instead. *My* initial expectation was that 'bzr lp-submit -m ...' would have set the initial comment (and not popped up an editor). Though probably that is because *bzr* doesn't use the Commit Message field in Launchpad for anything. (We set it at pqm-submit time.)
However, using -m is probably fine, as it does mimic pqm-submit -m and commit -m for a system like Tarmac.
I would think you'd want a similar --comment="And here is my summary comment" flag, though.
2) The code seems fine. No tests, but it generally needs to be tested against Launchpad anyway.
| Martin Pool (mbp) wrote : | # |
This would be good to add.
Needs news.
Needs a mention in the user guide.
The help for cmd_lp_submit doesn't really explain what this does or why you would want to use it. It looks like creates a merge proposal or requests a merge - that's what the Launchpad UI calls it but this seems to have no connection.
| Martin Pool (mbp) wrote : | # |
It also ought to document, eg by way of an example, or in the option help, what the reviewers option does and its syntax.
Would it be better to just call this "lp-propose" rather than "lp-submit"? To me "submit" is equally likely to mean 'submit to pqm' after you're done.
lp_submit.py needs a copyright statement.
415 + except restful_
416 + for line in e.content.
417 + if line.startswith
418 + break
419 + print line
This should probably turn it into an error raised to the caller?
The following are optional or follow-ons:
It would be nice to test it at least down to the layer of the lp api, either through function calls or a --dry-run option.
some of the lp code could be in common parts, but it can be refactored later.
| Martin Pool (mbp) wrote : | # |
Oh, also, I suppose this should say that it will then open the mp in a browser.
As a follow-on one might want the option to turn this off.
| Martin Pool (mbp) wrote : | # |
I tested this interactively and it's really very nice, cleaning up a snag in the process.
It takes a while to get going so it would be good if it said just what it is doing.
It would also be nice if the message editor told me about the revisions newly added and perhaps showed their diff - in fact that would be a bit of a killer feature over Launchpad.
| Aaron Bentley (abentley) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John A Meinel wrote:
> *My* initial expectation was that 'bzr lp-submit -m ...' would have set the initial comment (and not popped up an editor). Though probably that is because *bzr* doesn't use the Commit Message field in Launchpad for anything. (We set it at pqm-submit time.)
The new lp-land command in bzr-pqm does use the commit message field.
> I would think you'd want a similar --comment="And here is my summary comment" flag, though.
So far, I haven't wanted that. In fact, one of the major advantages of
the command is that, like "bzr send" it allows a template proposal
message to be supplied. Launchpad's hook even includes lint output.
Providing an initial merge comment at the command line loses that
advantage. So I'm not sure it's worthwhile, though of course I wouldn't
block a reasonable implementation of it, if someone wanted to do that.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt
gKEAnA6F6BspWrc
=Lzkm
-----END PGP SIGNATURE-----
| Aaron Bentley (abentley) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> Review: Needs Fixing
> It also ought to document, eg by way of an example, or in the option help, what the reviewers option does and its syntax.
Done.
> Would it be better to just call this "lp-propose" rather than "lp-submit"?
I've gone for maximum clarity and called it lp-propose-merge, with
lp-propose and lp-submit as aliases.
> To me "submit" is equally likely to mean 'submit to pqm' after you're done.
To me, the effect of submitting something should depend on what you're
submitting it to.
> lp_submit.py needs a copyright statement.
Done.
> 415 + except restful_
> 416 + for line in e.content.
> 417 + if line.startswith
> 418 + break
> 419 + print line
>
> This should probably turn it into an error raised to the caller?
Done.
> The following are optional or follow-ons:
I'll leave those for later.
> Oh, also, I suppose this should say that it will then open the mp in a browser.
Done.
> As a follow-on one might want the option to turn this off.
I'll leave that for later. (For the record, I *always* want it opened
in a browser, because once it's been proposed, I need to communicate
with potential reviewers about it.)
> It takes a while to get going so it would be good if it said just
> what it is doing.
I suppose. The sad thing is, AFAICT, the delay is the time it takes to
log into Launchpad.
> It would also be nice if the message editor told me about the
> revisions newly added and perhaps showed their diff - in fact that would
> be a bit of a killer feature over Launchpad.
Yes, that could be nice, but I prefer to see the diff in a terminal.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt
yKEAn0W8WD4vZVL
=XbZJ
-----END PGP SIGNATURE-----
| Aaron Bentley (abentley) wrote : | # |
About the user guide: it's in the command listing; isn't that enough? If not, where exactly do you want it to go?
| Martin Pool (mbp) wrote : | # |
I used this for all my proposals yesterday and it was really nice - thanks!
> > Would it be better to just call this "lp-propose" rather than "lp-submit"?
>
> I've gone for maximum clarity and called it lp-propose-merge, with
> lp-propose and lp-submit as aliases.
That's good, thanks.
> > To me "submit" is equally likely to mean 'submit to pqm' after you're done.
>
> To me, the effect of submitting something should depend on what you're
> submitting it to.
I don't understand - we could use 'submit' to mean 'commit' when you're submitting from a tree to a branch, but calling that 'submit' would just cause confusion.
I think having multiple synonyms for commands (that aren't abbreviations) was a mistake and just causes confusion about whether they're the same or not.
So unless there's some reason I'm not aware of for 'lp-submit' please remove that alias.
> > It takes a while to get going so it would be good if it said just
> > what it is doing.
>
> I suppose. The sad thing is, AFAICT, the delay is the time it takes to
> log into Launchpad.
(In passing https:/
| Martin Pool (mbp) wrote : | # |
> About the user guide: it's in the command listing; isn't that enough? If not,
> where exactly do you want it to go?
I think it should go into 'sharing with peers' in the user guide. Just a sentence or two making people aware that it exists is enough to let them chase the link to the help or user reference.
Also we should add it to help.l.n
| Andrew Bennetts (spiv) wrote : | # |
Martin Pool wrote:
[...]
> I think having multiple synonyms for commands (that aren't abbreviations) was
> a mistake and just causes confusion about whether they're the same or not.
Agreed — and I believe we've started taking steps to remove some of the
synonyms we already have, so adding more (even in a plugin) seems like a
step backwards.
| Aaron Bentley (abentley) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
>>> To me "submit" is equally likely to mean 'submit to pqm' after you're done.
>> To me, the effect of submitting something should depend on what you're
>> submitting it to.
>
> I don't understand - we could use 'submit' to mean 'commit' when you're submitting from a tree to a branch, but calling that 'submit' would just cause confusion.
I mean that 'submit' as a verb doesn't really suggest an outcome. If
you submit to a magazine, you may get an article published. If you
submit a premise, you may win an argument. If you submit to a PQM, you
may get your branch merged and committed. If you submit to Launchpad,
you may get your code reviewed. Note that whatever we call the command,
we will default to the "submit" branch as the target.
> I think having multiple synonyms for commands (that aren't abbreviations) was a mistake and just causes confusion about whether they're the same or not.
>
> So unless there's some reason I'm not aware of for 'lp-submit' please remove that alias.
The lp-submit command is well-established in the "bzr-pipeline" plugin.
The alias is to ease the transition for people used to using that name.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt
ELsAnj+
=cT4L
-----END PGP SIGNATURE-----
| Martin Pool (mbp) wrote : | # |
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin Pool wrote:
> >>> To me "submit" is equally likely to mean 'submit to pqm' after you're
> done.
> >> To me, the effect of submitting something should depend on what you're
> >> submitting it to.
> >
> > I don't understand - we could use 'submit' to mean 'commit' when you're
> submitting from a tree to a branch, but calling that 'submit' would just cause
> confusion.
>
> I mean that 'submit' as a verb doesn't really suggest an outcome. If
> you submit to a magazine, you may get an article published. If you
> submit a premise, you may win an argument. If you submit to a PQM, you
> may get your branch merged and committed. If you submit to Launchpad,
> you may get your code reviewed. Note that whatever we call the command,
> we will default to the "submit" branch as the target.
But this is just to say that submit is a very general verb, whereas if we're going to use it as the name of a command then having a more specific one is good.
Anyhow, changing the primary name and keeping the alias for compatibility is ok.
I would like to see the actual code changed to be 'propose' not 'submit'.
I would change canonical_url to something like web_url and make the replacement be
launchpad_
to make it more robust, and maybe add a comment pointing to https:/
aside from that, good to go, thanks.
- 4986. By Aaron Bentley on 2010-02-18
-
Merged bzr.dev into lpsubmit.
- 4987. By Aaron Bentley on 2010-02-18
-
Fix divergence check.
- 4988. By Aaron Bentley on 2010-02-18
-
Rename submit to propose everywhere.
- 4989. By Aaron Bentley on 2010-02-18
-
Fix exception handling.

Hi all,
This branch introduces the lp-submit command, originally from the bzr-pipeline
plugin.
It includes two hooks, one for determining the prerequisite branch, and one
for determining the message body. The pipeline plugin will use the first
to supply the previous pipe as the prerequisite branch. The lpreview_body
plugin will use the second to supply a body following Launchpad policies.
This merge proposal was, itself, submitted using the lp-submit command.