This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: onwards to git
On Thu, 30 Apr 2009, Roland McGrath wrote:
> I agree with the consensus that we want to keep the one ports tree we have.
> Using git already means there is a much better way to manage the commits
> than we have had before.
>
> Each port has an authoritative person or set of people. Those maintainers
> will fork their own active-work repositories from the canonical ports git
> repository and easily share them amongst themselves (even without using
> extra git magic, the whole ports repo is ~6M, easy to host a copy on your
> own web servers). Then post a "git request-pull" message, and a ports
> gatekeeper can do a trivial pull/push operation to merge the trees.
>
> Given the lack of access control in our git setup, it's in fact easy for
> any individual port maintainer to just do "git push" when approved.
Given the low rate of ports patches and that most of those from people
with write access are to the ports they maintain and don't need separate
review, just pushing patches also seems likely to be the natural approach
in most cases. We don't really have a problem with ports commits. (There
may be a problem with *review* of patches for the alpha port, but that's a
matter of lack of someone with the right expertise to review them.)
The possibility of request-pull messages could be more useful for libc if
the libc maintainers find it a better way e.g. to take patches reviewed by
the people who tend to review patches for SH or SPARC. libc patches do
sometimes seem to take a long time to be reviewed, or to be committed
after an architecture expert without write access has reviewed them (e.g.
I have a SPARC patch a SPARC expert reviewed at
<http://sourceware.org/ml/libc-alpha/2009-03/msg00047.html> but no review
from someone with write access); if improved technology means libc patches
submitted in a particular way are likely to be reviewed promptly and
pulled if OK, that would be very useful.
--
Joseph S. Myers
joseph@codesourcery.com