Re: Patchwork patch tracking system

[Pedro Alves <palves@redhat.com>]

On 04/29/2014 08:33 PM, Breazeal, Don wrote:
> 
> 
>> -----Original Message-----
>> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
>> Behalf Of Pedro Alves
>> Sent: Tuesday, April 29, 2014 11:58 AM
>> To: Tom Tromey
>> Cc: Joel Brobecker; Gary Benson; Stan Shebs; gdb@sourceware.org
>> Subject: Re: Patchwork patch tracking system
>>
>> On 04/29/2014 06:07 PM, Tom Tromey wrote:
>>
>>> I've been trying the patchworks install as well.  I don't find it all
>>> that useful myself, but maybe it would be better if more people were
>>> using it.
>>
>> I've been trying it out too.  I've already found it useful to keep track
>> of which of my own patches I have pending.
>>
>> I've been absent a little while from review, but I'm heading back, and
>> I'm using patchwork to guide me.
>>
>> I like that it doesn't make the mailing list a second class citizen.
>> I'd be willing to continue giving it a try, but indeed I think it'd be
>> better if more people were using it.  That'll be true for any tool we
>> end up with.
>>
>> In the past week, I've been cleaning it up whenever I see that patches
>> have been pushed, even those that I didn't approve myself, but of course
>> it'd be better if who approves the patch or the submitter themselves
>> take care of their own patches.
>>
>> non-maintainers shouldn't hold back from creating an account and
>> updating the state of their own patches.  Whatever helps bringing the
>> load down from maintainers should help your own patches.  :-)
>>
>> Here's the current list of who-has-how-many-pending:
>>
>> $ ~/bin/pwclient-hacked list -s New | sort | uniq -c | sort -nr
>>      35 Andy Wingo <wingo@igalia.com>
>>      24 Andreas Arnez <arnez@linux.vnet.ibm.com>
>>      20 Yao Qi <yao@codesourcery.com>
>>      17 Jan Kratochvil <jan.kratochvil@redhat.com>
>>      16 Pedro Alves <palves@redhat.com>
>>      14 Siva Chandra <sivachandra@google.com>
>>      13 Keith Seitz <keiths@redhat.com>
>>      13 David Blaikie <dblaikie@gmail.com>
>>      12 Andrew Burgess <aburgess@broadcom.com>
>>       9 Doug Evans <dje@google.com>
>>       4 Kyle McMartin <kmcmarti@redhat.com>
>>       4 Hui Zhu <hui_zhu@mentor.com>
>>       3 Simon Marchi <simon.marchi@ericsson.com>
>>       3 Eli Zaretskii <eliz@gnu.org>
>>       3 Alan Modra <amodra@gmail.com>
>>       2 Ulrich Weigand <uweigand@de.ibm.com>
>>       2 Mike Frysinger <vapier@gentoo.org>
>>       2 Doug Evans <xdje42@gmail.com>
>>       2 Alexander Smundak <asmundak@google.com>
>>       2 Agovic, Sanimir <sanimir.agovic@intel.com>
>>       1 Vladimir Nikulichev <nvs@tbricks.com>
>>       1 Tom Tromey <tromey@redhat.com>
>>       1 Sandra Loosemore <sandra@codesourcery.com>
>>       1 Pierre Langlois <pierre.langlois@embecosm.com>
>>       1 Nick Clifton <nickc@redhat.com>
>>       1 Mateusz Tabaka <8tab@wp.pl>
>>       1 Mark Wielaard <mjw@redhat.com>
>>       1 Marcus Shawcroft <marcus.shawcroft@arm.com>
>>       1 Marc Khouzam <marc.khouzam@ericsson.com>
>>       1 Maciej W. Rozycki <macro@codesourcery.com>
>>       1 Julian Brown <julian@codesourcery.com>
>>       1 John Marino <gnugcc@marino.st>
>>       1 Gary Benson <gbenson@redhat.com>
>>       1 David Taylor <dtaylor@emc.com>
>>       1 Daniel Gutson <daniel.gutson@tallertechnologies.com>
>>
>> As you see, most of the patches so far, since we began tracking a few
>> weeks back, came from a small set of people.  And I suspect many of
>> those are actually already in.
> 

> A patch series that I posted to gdb-patches at the beginning of April doesn't seem to show up in patchwork.  It would be good to understand why that is and how to fix it.
> https://sourceware.org/ml/gdb-patches/2014-04/msg00037.html
> https://sourceware.org/ml/gdb-patches/2014-04/msg00040.html
> https://sourceware.org/ml/gdb-patches/2014-04/msg00072.html
> https://sourceware.org/ml/gdb-patches/2014-04/msg00071.html

Well, I suspect it's the same reason your patch doesn't show
inline in those urls -- follow the "raw" link and we see:

--_002_DA279C53C4A5884A907135DFCD7A059A0E1D95BDNAMBX02mgcmento_
Content-Type: application/octet-stream; name="0001-remote-exit.patch"
Content-Description: 0001-remote-exit.patch
Content-Disposition: attachment; filename="0001-remote-exit.patch"; size=9688;
	creation-date="Wed, 02 Apr 2014 21:17:10 GMT";
	modification-date="Wed, 02 Apr 2014 21:35:13 GMT"
Content-Transfer-Encoding: base64

You need to either inline the patch in the body of the email,
or make Content-Type be some kind of "text".  For ".patch" files,
that's usually text/x-patch.

Compare with Sandra's, which is also sent as an attachment:

 https://sourceware.org/ml/gdb-patches/2014-03/msg00602.html


I don't have access to patchwork's logs, but looking around current
git mainline patchwork's sources, I see,
in apps/patchwork/bin/parsemail.py:

 150 def find_content(project, mail):
 151     patchbuf = None
 152     commentbuf = ''
 153     pullurl = None
 154
 155     for part in mail.walk():
 156         if part.get_content_maintype() != 'text':
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 157             continue
 158
 159         payload = part.get_payload(decode=True)
 160         charset = part.get_content_charset()
 161         subtype = part.get_content_subtype()
 162
 163         # if we don't have a charset, assume utf-8
 164         if charset is None:
 165             charset = 'utf-8'
 166
 167         if not isinstance(payload, unicode):
 168             payload = unicode(payload, charset)
 169
 170         if subtype in ['x-patch', 'x-diff']:
 171             patchbuf = payload
 172
 173         elif subtype == 'plain':
 174             c = payload
 175
 176             if not patchbuf:
 177                 (patchbuf, c) = parse_patch(payload)
 178
 179             if not pullurl:
 180                 pullurl = find_pull_request(payload)
 181
 182             if c is not None:
 183                 commentbuf += c.strip() + '\n'
 184
 185     patch = None
 186     comment = None
 187
 188     if pullurl or patchbuf:
 189         name = clean_subject(mail.get('Subject'), [project.linkname])
 190         patch = Patch(name = name, pull_url = pullurl, content = patchbuf,
 191                     date = mail_date(mail), headers = mail_headers(mail))
 192
 193     if commentbuf:
 194         if patch:
 195             cpatch = patch
 196         else:
 197             cpatch = find_patch_for_comment(project, mail)
 198             if not cpatch:
 199                 return (None, None)
 200         comment = Comment(patch = cpatch, date = mail_date(mail),
 201                 content = clean_content(commentbuf),
 202                 headers = mail_headers(mail))
 203
 204     return (patch, comment)


So it looks like patchwork just skips your attachments, (rightfully) considering them blobs.

Full source here:

 http://git.ozlabs.org/?p=patchwork;a=blob;f=apps/patchwork/bin/parsemail.py;h=b6eb97ad827a8f499e763dc99c297e2c0b6e4a8f;hb=HEAD

I suggest just using "git send-email" to send patches.  It makes sending
patch series _so_ much easier, it enforces following good practices
commit log practices, and makes sure the receiving end has it easy too -- one
can just save the emails as mbox files (from the mail client, or patchwork's
web frontend -- see e.g., the "mbox" link at http://patchwork.siddhesh.in/patch/660/)
and then simply use "git am" to import the result.  Or using patchwork's
command line tool, do that in one step with "pwclient git-am $patch_id".

-- 
Pedro Alves