Re: Patchwork patch tracking system

[Pedro Alves <palves at 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
> 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