|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|* '''Launchpad Entry''': https://launchpad.net/products/bzr/+spec/SubmitByMail||* '''Launchpad Entry''': https://launchpad.net/products/bzr/+spec/submitbymail|
|Line 173:||Line 173:|
|* I'm currently trying to extend pqm so it handles the messages sent with this plugin.|| * The plugin was extended with an apply command. The modified rule from the "rationale" section would look like this:
* ^TOmy bzr repo
|(umask 022; cd /path/to/your/repo; bzr apply --keyring /path/to/the/allowed_keys)
* I've created a pqm branch that checks if a patch is in fact a bundle and then applies using bzr's bundle functions. https://launchpad.net/people/c3po/+branch/pqm/bundles
The plugin is available from: https://launchpad.net/products/bzr-submit
Launchpad Entry: https://launchpad.net/products/bzr/+spec/submitbymail
PQM provides a way to submit merge requests by email and have them automatically applied. It might be nice if this were smoothly integrated with bzr.
Erik Bågfors <email@example.com> to mbp, Bazaar-NG How about adding this kind of functionality into bzr itself? Look at how darcs handles it. It's one if the nicest things about darcs. a darcs "server" can simply be a mail address you mail to, that runs all mails trough pgp and then applies them if they match (you can add tests as well by just adding "apply test" to the repo config file). for example a procmail can look like this :0: * ^TOmy darcs repo |(umask 022; darcs apply --reply firstname.lastname@example.org \ --repodir /path/to/your/repo --verify /path/to/the/allowed_keys) That's a dead simple way to set up a "server" for trusted people to submit to. I don't know how pqm works and it might be lot's better, but having this functionality built into bzr has lot's of advantages I think.
This has the big advantage that no special kind of server is required. A procmail rule is something almost anyone can set up, including on a desktop/firewalled/not-permanently-connected machine.
It would be nice to send the changes as a series of bzr changesets (as mentioned on BzrWishlist).
There should be one command to send the changeset (bzr submit), and one to apply the changeset (bzr apply), to be called manually or from a procmail rule.
There are lots of tools to do some sort of diff, mail it, and then apply it on the other end. A simple bzr diff -r -10 | gpg --cl | mail email@example.com will be able to do a reasonable job of sending a signed change to a mailing list. It is assumed that people who want a bzr submit command would also like to attach some meta-data. It is possible to create a text-based changeset format, which contains all of the meta-information which bzr maintains, and apply it on the other end, so that it has all the features of doing a bzr merge against the original branch.
- User grabs a public branch, finds a bug, and wants to submit back a small patch back to the mailinglist. The nice use case would be:
$ bzr branch http://public.com/project $ cd project <hack hack> $ bzr commit -m "Fixed my little bug" $ bzr submitPeople can review the final changes in their mail program, and finally decide to apply this change and commit it:
<save the email to a file> cat file | bzr apply # or bzr apply file <double check things are okay> bzr commit -m "Applied the change from foo"
As a maintainer, I use bzr submit to submit my changes to a pqm. However, since others would not have commit access to the pqm, I want to specify that submissions should go to the mailing list. I publish my branch using rsync.
- I would like to automatically maintain a branch, such that I can submit to it using email, with a simple procmail filter.
To allow bzr branch to know how to set the submit target, there should be a file in the .bzr/ directory indicating the target. To allow for a different target for people who branch from me, versus my default branch target, there should be 2 files. (.bzr/submit-to and .bzr/children-submit-to) bzr branch should be smart, such that when it creates a branch, it will use .bzr/children-submit-to if it is available.
There would be one command, bzr submit, with several options and configuration variables.
Basic usage would be:
bzr submit -r ancestor:http://target/uri.. --output /tmp/changeset.bzr
bzr submit -r ancestor:http://target/uri.. --mail firstname.lastname@example.org
Of course -r would be standard revision specification. It would be exclusive for the start (except when only one revision is given) for convenience of the above notation.
There would be a shortcut
bzr submit --target http://target/uri ...
for the -r option. This value would be remembered by config and default to parent or push target.
There would be a bit of DWIMmeryFootNote(DWIM = Do What I Mean) for the second argument -- if a non-option argument is given
and looks like an email address (can be forced with mailto:), it is treated as argument to --mail.
if the argument looked like URL or path, which exists and is a directory, it would be treated as argument of --target.
else it would be treated as argument to --output (- should be understood to mean stdout)
-- Be carefull that this is ambiguous. How do you save in a file containing a '@' in its name? To you distinguish between a filename (--output) and a path (--target), you need to see if the branch exists. If you misstyped the name, you'll get one behavior instead of the other. I find it confusing (but if the non-ambiguous options are there, that's probobly OK) --MatthieuMoy
Plus of course this would be remembered by config as well. So if you once did:
bzr submit http://bazaar-ng.org/bzr/bzr.dev email@example.com
you could then just do:
And it would just do the right thing.
There would be one more option, which would only be used together with --mail -- --mua. It would be a command to run the mailer. It could either be a format string (containing %(to)s for recipient address and %(file)s for the changeset file -- it would be assumed that the mua will make it an attachment). Plus for common MUAs (mailx, mutt, mh, af, gnus...) bzr could know how to pass the arguments, so one could only type in their name. There would of course be respective config option.
Merge changeset code into core
Track default submit location (Can track more than one location per branch, i.e. one for the maintainer and one for a contributor)
Is it useful to keep track of what has already been sent to a particular destination?
Command format will look like this:
Message is used as the subject. Address recognizes the prefix "mailbot:". options: --address ARG Overides the default address. --dry-run Print message instead of sending --help, -h show help message --message ARG, -m --message-file ARG Read the message text from this file --remember Remember the specified location as a default. --revision ARG, -r --target ARG Select a different target address (e.g. pqm, mailinglist)
If no subject is given the last log message is used and prefixed with [PATCH]. If no message is given an editor is launched.
Questions and Answers
Summer of Code
I (HermannKraus) am doing this job as my Summer of Code project. My code will be based on John Meinel and Aaron Bentley's bundle (changeset) code which already provides a good format for transmitting all the meta data.
- Automated signing of the patch with gpg.
- Samples rules for automatically applying the changes after verifying the senders identity.
- Remembering the address patches are submitted to and a default address that is active after branching.
- Configurable mailer command.
- Display a message before submitting a patch to a public mailing list.
RobHolland considers the following as the criteria for success of the Summer of Code project
'bzr branch http://bazaar-vcs.org/bzr/bzr.dev; <hack hack>; bzr commit; bzr submit' will email a signed bundle to the bzr mailing list
- bzr is capable of applying a valid bundle
- bzr gracefully handles a corrupted bundle
- there is a mechanism for automatically applying bundles authored by a set of gpg keys
- there is a mechanism for automatically applying any bundle with a valid signature
- Bundles (aka changesets) have been merged into bzr core
- After long discussions we came to the conclusion that signing should be left to the mail program (which might be bzr) and not be done in bazaar.
- The plugin that provides the submit command is mainly finished. The most important feature missing at the moment is launching an user-defined mail program when sending messages to a mailinglist and not to pqm.
- The plugin was extended with an apply command. The modified rule from the "rationale" section would look like this:
:0: * ^TOmy bzr repo |(umask 022; cd /path/to/your/repo; bzr apply --keyring /path/to/the/allowed_keys)
I've created a pqm branch that checks if a patch is in fact a bundle and then applies using bzr's bundle functions. https://launchpad.net/people/c3po/+branch/pqm/bundles
The plugin is available from: https://launchpad.net/products/bzr-submit