This is the mail archive of the
mailing list for the GDB project.
Re: Patchwork patch tracking system
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>, Joel Brobecker <brobecker at adacore dot com>
- Cc: Gary Benson <gbenson at redhat dot com>, Stan Shebs <stanshebs at earthlink dot net>, gdb at sourceware dot org
- Date: Wed, 21 May 2014 18:18:06 +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> <87tx8jnq7j dot fsf at fleche dot redhat dot com>
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
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:
(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
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
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:
> 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.