Patchwork for glibc?

[Joseph S. Myers]

On Fri, 14 Feb 2014, Ramana Radhakrishnan wrote:

> 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.

I very rarely do that.  Sometimes I look at the source files that the 
patch changes, only rarely do I apply a patch (generally a GCC patch) and 
build it because in the course of review I came up with a hypothesis about 
a problem with the patch that I wanted to test before saying that there is 
indeed a problem.

> 1. How does one specify the branch for a patch submission over email
> to allow a seamless interaction with the web interface .

It's mainline.  That covers 90% of the problem.

> 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)

For the binutils+gdb conversion to git I deliberately discouraged trying 
to include lots of other projects at the same time - instead stating the 
principle that each project should be able to choose independently if it 
wished to move away from CVS, and if so, what system to use for its 
repository.

The same applies to patch tracking / review - let each project work out 
what's good for it.  For glibc, we only need to handle git for any 
version-control integration.  (Of course some people may have their own 
branches in different systems, but such internal branches are irrelevant 
here.)

> 3. Dealing with approval followed by rejection or reversal of the patch.

Note that for glibc "approval" is fuzzy - you need to judge consensus, and 
for some changes this may not be a simple matter of counting yes/no votes 
but weighing the views expressed.  Outside documented consensus areas for 
obvious patches, and architecture-specific maintainers, we don't have 
defined rules "person X can approve patches in area Y".

(So if someone comments on a patch, and it hasn't been committed, that 
means action may be required, but doesn't necessarily say whether the 
action is commit, further review, patch revision or withdrawal of the 
patch; the submitter may need to judge that.)

-- 
Joseph S. Myers
joseph@codesourcery.com