On Tue, 2012-10-23 at 11:18 +0200, Petr Viktorin wrote: > On 10/23/2012 03:04 AM, Simo Sorce wrote: > > On Mon, 2012-10-22 at 18:03 -0400, Simo Sorce wrote: > >> Hello fellow developers, > >> > >> We have discussed for a while among us about how to improve patch > >> tracking for review purposes. Various method have been discussed for > >> quite some time now (including gerrit and review board) but for one > >> reason or another we haven't done much. > >> > >> I have now set up a patchwork instance here: > >> https://patchwork.acksyn.org > >> > >> Patchwork is a very lightweight system that doesn't take over our > >> current practices (although may require minor changes). > >> > >> Most importantly it does not replace our mailing list with a new system > >> that pretends to take over the whole process. > >> > >> With patchwork review happens on the mailing list as usual but the > >> server does automatic tracking of patches updating with comments sent to > >> the mailing list. > >> > >> Feel free to get a login there, and start managing your own patches. > >> I will keep a look on the system and override patch status for those > >> that choose not to use it. > >> > >> The server has just been installed and I am still configuring it. > >> If you have any issue please contact me privately or on this list so we > >> can try to address it. > >> > >> I hope we will find the tool useful. > >> > >> There is just one thing that patchwork does not handle well, and that is > >> multiple patches sent in the same mail as attachment. > >> See what happend here: https://patchwork.acksyn.org/patch/2 where I sent > >> three patches and only the last one was picked up by the system. > >> > >> Patchwork[1] has been developed mostly in the kernel community and there > >> the rule is to send 1 patch per mail by using git send-mail. > >> > >> I will switch to use git send-mail (and resend the above set as a test) > >> so that patchwork is happy, I hope you all can try to use it as well so > >> that we can try to use patchwork for all patches. > >> However I do not want to force people to use git send-mail. > >> If you are not going to use git send-mail however I would like to ask > >> you to not send more than one patch per mail message, and instead send > >> different patches in different messages. > >> Traditionally this is done by using a patchset header of [PATCH 0/5] and > >> then following one mail per patch [PATCH 1/5] and then PATCH[2/5] > >> etc ... the subject should stay the same for all patches in the same > >> patchset. > >> > >> If you have questions or proposal please let me know. > >> > >> Also patchwork is python+django so if you have an itch and want to > >> scratch it then feel free to send patches to me as well as upstream so > >> we can improve the tool. > > > > > > In case you wonder how to use git send-mail here are a couple of things > > I do to make it easier. > > > > 1. I cloned my public review repo on the machine I use for email so I > > can push directly from there even when the patches are built on my > > development machines. > > > > 2. set the [sendemail] option for the outgoing smtp server in > > ~/.gitconfig > > > > 3. I create 2 aliases that make the process just s simple 2 commands: > > > > alias prep-freeipa='rm -fr $HOME/git-send-mail && git format-patch -M -C > > --patience --full-index -n --cover-letter -o $HOME/git-send-mail' > > alias send-freeipa='git send-email --no-chain-reply-to --to > > "freeipa-devel@redhat.com" --suppress-cc=all $HOME/git-send-mail/*patch' > > > > This first alias is called like this: > > $ prep-freeipa -3 > > > > It will create a bundle for the lst 3 patches in the tree and dump > > patches as well as a standard cover letter in a directory called > > $HOME/git-send-mail > > > > I then vim $HOME/git-send-mail/0000-cover-letter.patch, where you need > > to add a subject and fill in the body of the presentation email > > > > Then call simply send-freeipa without any option. > > It will ask a couple of questions to which you can normally just hit > > return (defaults are usually ok). > > > > HTH, > > Simo. > > > > Thanks. I do have some critique. Hopefully it's just unfounded > resistance to change: > > The fact that patches are now e-mails, not files, makes it a bit harder > to work with them. Also, they do not have filenames. We'll need to > reword https://fedorahosted.org/freeipa/wiki/PatchFormat.
True, however git-am picjs up email messages just fine, so if you just save the email message and then git-am it will just work. This is how it is done in kernel land which shaped patchwork. NOTE: you can also save a whole bundle (grouping of patches in patchwork) as a single mbox file, and then use git-am on it. > I'm not sure about the separate emails thing. More patches per e-mail > made it clear what's dependent on what, and probably made it easier to > ensure the whole thing is pushed at once. If you see the patchset I sent you'll see it is pretty clear it is a bundle and what is the order and that they are dependent :) I used the --no-chain-... option in send-email so all patches are reply only to the first one, but if you use the chain option then each mail will be in reply to the previous one so they will be ordered in the thread. > With the current practice, > sometimes patches are forgotten, and I fear this will worsen. Well I set this up just to avoid that, if all patches are there you see very clearly which ones are still to be acted upon. With mail it's not so simple. > I guess if Thunderbird can be somehow taught to treat the patch mails as > replies to the cover letter, it would be better than we have now. Alas, > it didn't do so for the patches you've sent. I strongly suggest you use git-send-email instead of thunderbird, it makes everything a lot faster, see the instructions I sent in my followup email. > What's the preferred workflow for applying git-sent patches? It seems > that in Thunderbird, I need to View Source: Ctrl+U, Ctrl+A, Ctrl+C, and > copy that to a console with `git am` running. save the whole mail message in a file and git-am, or download the patch from patchwork :-) HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel