From: Tom Tromey <tromey@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Gary Benson <gbenson@redhat.com>,
Stan Shebs <stanshebs@earthlink.net>,
gdb@sourceware.org
Subject: Re: Patchwork patch tracking system
Date: Wed, 21 May 2014 14:47:00 -0000 [thread overview]
Message-ID: <87tx8jnq7j.fsf@fleche.redhat.com> (raw)
In-Reply-To: <8738gw6p4b.fsf@fleche.redhat.com> (Tom Tromey's message of "Tue, 29 Apr 2014 11:07:32 -0600")
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.
At the very least it gives us a global list of what has not been
reviewed. And, the patchwork command-line client seems quite nice;
"pwclient git-am" seems truly useful, though I haven't had cause to use
it yet.
A few things would make it nicer for use with gdb:
1. If it knew about patch series. Right now it drops (the usually quite
useful) "patch 0" mail and treats each patch as a separate entity.
I looked at the patchwork mailing list and while this topic has come
up, nobody has implemented the needed features.
2. Building on #1, if it could tell when a patch series obsoletes an
older series.
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.
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.
4. If we ran the existing patchwork automatic zapper regularly so that
commits could remove patches from the UI.
One final thing that would be useful is if a mention of a PR in a
gdb-patches mail caused some note to be posted to Bugzilla -- ideally a
link to the email in our archives, but a link to the appropriate entry
in patchwork would be an acceptable substitute.
Tom
next prev parent reply other threads:[~2014-05-21 14:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 10:08 Gary Benson
2014-04-04 22:50 ` Stan Shebs
2014-04-17 18:18 ` Gary Benson
2014-04-22 15:40 ` Joel Brobecker
2014-04-22 15:51 ` Eric Christopher
2014-04-22 18:37 ` Joel Brobecker
2014-04-24 11:42 ` Siva Chandra
2014-08-02 14:25 ` Mike Frysinger
2014-04-29 17:25 ` Tom Tromey
2014-04-29 17:36 ` Eli Zaretskii
2014-04-29 18:58 ` Joel Brobecker
2014-04-30 9:19 ` Gary Benson
2014-04-30 12:45 ` Joel Brobecker
2014-04-29 19:33 ` Pedro Alves
2014-04-29 22:32 ` Breazeal, Don
2014-04-30 1:08 ` Pedro Alves
2014-04-30 3:45 ` Breazeal, Don
2014-05-21 14:47 ` Tom Tromey [this message]
2014-05-21 17:18 ` Pedro Alves
2014-05-21 17:49 ` Joel Brobecker
2014-05-21 18:03 ` Eli Zaretskii
2014-05-21 18:23 ` Joel Brobecker
2014-05-21 18:48 ` Eli Zaretskii
2014-05-21 19:45 ` Joel Brobecker
2014-05-21 21:35 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tx8jnq7j.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=brobecker@adacore.com \
--cc=gbenson@redhat.com \
--cc=gdb@sourceware.org \
--cc=stanshebs@earthlink.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox