From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12902 invoked by alias); 21 May 2014 17:18:16 -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 12891 invoked by uid 89); 21 May 2014 17:18:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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; Wed, 21 May 2014 17:18:13 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4LHI9hH004220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 13:18:09 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4LHI6HX004994; Wed, 21 May 2014 13:18:07 -0400 Message-ID: <537CDFCE.7000407@redhat.com> Date: Wed, 21 May 2014 17:18:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tom Tromey , Joel Brobecker CC: Gary Benson , Stan Shebs , 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> <87tx8jnq7j.fsf@fleche.redhat.com> In-Reply-To: <87tx8jnq7j.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00038.txt.bz2 On 05/21/2014 03:47 PM, Tom Tromey wrote: > Tom> I've been trying the patchworks install as well. I don't find it all > Tom> that useful myself, but maybe it would be better if more people were > Tom> using it. > > Let me walk that back a little. > > I've been trying it again and it is useful. I've been using it every > day. Just to reinforce, in case people wonder whether previous users backed out -- I still use it, and find it useful. One useful thing even if you're not interested in others' patches is getting the list of your own patches that are pending. For example, I get mine here: http://patchwork.siddhesh.in/project/binutils-gdb/list/?submitter=37 (I just have that bookmarked) It's easy to find one's URL, by hitting the "Filters" link at the top of the patches table, and filtering by submitter. That'll take you to such an url. > 2. Building on #1, if it could tell when a patch series obsoletes an > older series. Obviously, even for single patches. But I think any patch tracking system will require some sort of action to have a patch obsolete some other as opposed to adding more on top. > I think this would work best with patch series support, because it's > common when resubmitting for patches to change their subject and > otherwise be "untrackable", whereas we could easily adopt a > convention that the new series have the same title for the cover > letter. Yeah. I think this would be a nice to have, but if people (at least frequent submitters) care for their own patches, then this really isn't a big problem. > 3. If it ignored "FYI" patches. This step could be applied after #2 so > that the final courtesy copy would zap the old series from the UI. I know you know this, but for others -- I'm getting around this by running this script once in a while: pwclient list -s New | grep -i "\[.*commit.*\]\|\[.*pushed.*\]\|\[.*fyi.*\]" | cut -f 1 -d ' ' | while read patch; do printf "updating %d: " $patch pwclient info $patch | grep " name *:" | sed 's/^- name *: //' pwclient update -s Accepted $patch done That uses the command line client to "Accept" "New" patches patches that have [commit], [commit] or [fyi] in its subject. You can find it at: https://github.com/palves/misc/blob/master/patchwork/pwupdate-already-pushed > 4. If we ran the existing patchwork automatic zapper regularly so that > commits could remove patches from the UI. I'm not certain that would work for us, unless we change some process. I am under the impression that that matches commits by git hash. The fact that the ChangeLog is usually not a part of the patch and then is added before push changes the hash. Also, given we only allow fast-forward, it's very frequent that patches need to be rebased when pushed, which changes hash as well. -- Pedro Alves