From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3613 invoked by alias); 29 Apr 2014 22:32:39 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 3602 invoked by uid 89); 29 Apr 2014 22:32:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,URIBL_SBL autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Apr 2014 22:32:36 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3TMWSi2025773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Apr 2014 18:32:29 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3TMWQSv027997; Tue, 29 Apr 2014 18:32:27 -0400 Message-ID: <5360287A.3050407@redhat.com> Date: Wed, 30 Apr 2014 01:08:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Breazeal, Don" CC: Tom Tromey , "gdb@sourceware.org" Subject: Re: Patchwork patch tracking system References: <20140402100842.GA956@blade.nx> <533F3713.40700@earthlink.net> <20140417135040.GA891@blade.nx> <20140422130652.GG5790@adacore.com> <8738gw6p4b.fsf@fleche.redhat.com> <535FF637.1080405@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00086.txt.bz2 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 >> 24 Andreas Arnez >> 20 Yao Qi >> 17 Jan Kratochvil >> 16 Pedro Alves >> 14 Siva Chandra >> 13 Keith Seitz >> 13 David Blaikie >> 12 Andrew Burgess >> 9 Doug Evans >> 4 Kyle McMartin >> 4 Hui Zhu >> 3 Simon Marchi >> 3 Eli Zaretskii >> 3 Alan Modra >> 2 Ulrich Weigand >> 2 Mike Frysinger >> 2 Doug Evans >> 2 Alexander Smundak >> 2 Agovic, Sanimir >> 1 Vladimir Nikulichev >> 1 Tom Tromey >> 1 Sandra Loosemore >> 1 Pierre Langlois >> 1 Nick Clifton >> 1 Mateusz Tabaka <8tab@wp.pl> >> 1 Mark Wielaard >> 1 Marcus Shawcroft >> 1 Marc Khouzam >> 1 Maciej W. Rozycki >> 1 Julian Brown >> 1 John Marino >> 1 Gary Benson >> 1 David Taylor >> 1 Daniel Gutson >> >> 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