Re: Patchwork for glibc?

[Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>]

Thanks for your email - some of this is what I want from a system as
well and in addition a couple of features which may end up being at
cross-purposes with you.


On Fri, Feb 14, 2014 at 6:18 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Fri, 14 Feb 2014, Ramana Radhakrishnan wrote:
>
>> I'm quite tired as well of stale patches in mailboxes and the
>> associated pain we have in all the communities. I've got a few ideas
>> based on looking at some available tools like phabricator and
>> reviewboard but I'm not in a position to have a meaningful discussion.

Each of the tools I've listed has their own pros and cons and I'm not
about to go into all that in great detail other than to take a couple
of examples.. I wasn't prepared to write all this down today but here
are some of my thoughts.

>
> What I want from any system supporting patch review is:


>
> * No need to use a special tool to submit a patch; patches can be sent
> with normal mail clients and so be in greppable form in one's sent mail
> folders.  (This does not say whether there could be some
> patch-tracking-submission email address that's CC:ed as well as the list,
> or whether patches could be sent to such an address that then sends them
> on to the list.)

Yes - hopefully get it to accept new submissions over email. A command
line tool should be an optional extra for those who want to use that
integrated with a version control tool but this should not mandate
just one version control tool.

>
> * Patches, whether or not anyone uses some special tool to submit them,
> arrive in mailboxes in normal plain-text emails to the mailing list, so
> can be found through grep of mail folders from the list and are archived
> in all archives of the list.

Agreed

>
> * Patches can be reviewed in normal plain-text emails to the mailing list
> without any special tool being needed.  If someone uses some other tool to
> review a patch, this generates such an email, on the list, in the right
> thread, with meaningful context based on the reviewer's choice of which
> parts of the patch should be quoted in the review (not just quoting too
> little context, not just giving line numbers, not quoting the whole thing
> without trimming irrelevant pieces), so reviews can also be found through
> grep of mail folders to the list and are also archived in all archives of
> the list.

Figuring out if this works properly and reliably is the hard bit and
I'm not sure which tool does this properly.

Additionally  I find that applying the patch in my local tree to work
out context is something I spend a lot of time on. Is it just me that
does that ? Having a web interface integrated with the source
repository tends to help.

Marking reviews at the same time through the web interface does help
me rather than having to type out an email separately. I don't know if
other folks would like to do that but there are times when having the
entire context during reviews is useful to me. The challenge then is
to see how we can target the appropriate branch, bug number etc for
the patch. And I do wonder if it would help with more casual
reviewers. One of the challenges that I keep hearing in the various
GCC summits that I've been to for the past 10 years is about how we
increase the number of reviewers and if we can do something that
encourages it then maybe we should try such things ? Again Integrating
auto-CC's to maintainers of the appropriate areas would be really
helpful.

So, my additional requirement is that one should be tool should be
able to work with a variety of version control systems if people think
such a feature is useful.

>
> I believe patchwork achieves this by tracking whatever patches have gone
> to the list, regardless of what tools may have been used to send them.  It
> does need someone keeping an eye on the data and removing patches that
> have been committed, or reviewed and need revising.

What I don't like is this admin aspect for patches and reviews for
each project - that's effectively one person doing admin stuff per
project and I think developers doing this admin stuff regularly is
just a waste of their time. If patchwork with it's git hooks installed
in repositories can get the job done reliably then I'm all for it, but
I've not seen a successful implementation with that yet and any half
baked system is just going to fail like all the other ones.

Which is why I am slightly interested by Phabricator but I failed
miserably the last time I tried to install it and play with it. Maybe
this time things will work better when I actually have some time to
play with it :)

My additional requests with any patch review tool currently are:


1. How does one specify the branch for a patch submission over email
to allow a seamless interaction with the web interface .
2. How well does it integrate with svn / git / cvs which I think are
the 3 main version control systems that I think I'd care about today (
binutils+gdb, newlib, gcc , glibc, gcc/wwwdocs)
3. Dealing with approval followed by rejection or reversal of the patch.

1-2 seem manageable - 3 appears to be more esoteric.


regards
Ramana

>
> --
> Joseph S. Myers
> joseph@codesourcery.com