[Freeipa-devel] Experimental patchwork server

[Simo Sorce]

On Wed, 2012-10-24 at 10:40 +0200, Martin Kosek wrote:
> On 10/23/2012 03:53 PM, John Dennis wrote:
> > On 10/23/2012 09:00 AM, Simo Sorce wrote:
> >> 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.
> > 
> > I wrote a python script to manage my patch submissions a while ago which might
> > be useful to folks, it's attached.
> > 
> > The basic idea is you keep a directory of your patch submissions. Inside the
> > directory is also a file that has then next number to use for your submission.
> > By default it runs git format-patch selecting the last commit. It creates a
> > patch file using the patch submission format defined for IPA. If you use the -s
> > option it also sends it to the list. It doesn't use git-send-email, rather it
> > builds an email with a mime attachment according to our IPA recommendations. I
> > don't recall why I didn't use git-send-email, but there was some reason
> > (probably because I couldn't get it follow the IPA conventions, not sure though).
> > 
> > If you have to rework a patch use the -n option to specify which patch you're
> > modifying. The script automatically searches the patch directory and finds the
> > next revision number for the patch.
> > 
> > The config dict at the top will have to be modified to match your username,
> > smtp server, etc. look for anything in UPPERCASE and replace with your specifics.
> > 
> > I like to use it because I don't have to remember my patch numbers and the
> > result will always follow the IPA conventions without any fumbling around.
> > 
> > Petr3 will probably complain about using getopt and a config dict instead of
> > optparse but it works and it wasn't worth it to me to port it to a different
> > mechanism. Anybody which wants to is more than welcome.
> > 
> 
> Hmm, yeah, I have similar script of my own, except I implemented a support for
> sending a bulk of patches at once.

Should be easy to change it to send one per mail, however git send-email
here has features you want to replicate like setting the correct
in-reply-to header so they all belong to the same thread.

> I think I am just too conservative, but I am perfectly comfortable with my
> home-grown scripts which detect the next number(s) of sent patch, prepares me
> an e-mail with attachments I can further amend and the script also attaches the
> patch to Trac ticket.

It would be easy to change the script to use send-email and still do the
other things you need, git send-email doesn't prescribe patch numbers or
subjects.

> I think someone other already pointed it out, but numbering patches also make
> it easy both referring to them during discussions on IRC.

I find it easier to give out a URL with the bundle from patchwork :)
More than once lately I saw a number but multilpe people had similar
numbers in play, but I am not against using numbers, just find there are
simpler ways and not too critical.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York