This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Patchwork for glibc?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <ramrad01 at arm 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 20:07:14 +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>
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