This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Patchwork patch tracking system
- From: Pedro Alves <palves at redhat dot com>
- To: "Breazeal, Don" <donb at codesourcery dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 29 Apr 2014 23:32:26 +0100
- Subject: Re: Patchwork patch tracking system
- Authentication-results: sourceware.org; auth=none
- References: <20140402100842 dot GA956 at blade dot nx> <533F3713 dot 40700 at earthlink dot net> <20140417135040 dot GA891 at blade dot nx> <20140422130652 dot GG5790 at adacore dot com> <8738gw6p4b dot fsf at fleche dot redhat dot com> <535FF637 dot 1080405 at redhat dot com> <DA279C53C4A5884A907135DFCD7A059A0E1DC19E at NA-MBX-02 dot mgc dot mentorg dot 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