This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Patchwork for glibc?
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Jeff Law <law at redhat dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 14 Feb 2014 22:05:53 +0000
- Subject: Re: Patchwork for glibc?
- Authentication-results: sourceware.org; auth=none
- References: <52FE35BC dot 3000908 at redhat dot com> <52FE4FF4 dot 6090004 at redhat dot com> <CAJA7tRaK6_maeKQph2zCzKzc0JC7gpKzQLF3TOAhawrwJp7rsw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402141808310 dot 31722 at digraph dot polyomino dot org dot uk> <CAJA7tRZU7WX8iAQtiHLZWsD=t5RaSDjuAWT2AUiL3k9n9_bG0Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402141958360 dot 31722 at digraph dot polyomino dot org dot uk>
- Reply-to: ramrad01 at arm dot com
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