Patchwork for glibc?

[Ramana Radhakrishnan]

On Fri, Feb 14, 2014 at 8:07 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> 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.

True but that's a function of what the patch is touching and the
number of patches you get of that type.

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

mainline might be served by best by this, but reviews on a topic
branch might be useful to have at times.

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


True.


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

True.

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

It may be that the tools that are the best fit for glibc are not best
for other projects, so dealing with each in a separate and pragmatic
manner, learning from each other might be the most practical way to
proceed.

Ramana

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