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, Daniel Jacobowitz wrote:
> On Thu, Apr 30, 2009 at 10:47:43AM -0400, Carlos O'Donell wrote:
> > On Thu, Apr 30, 2009 at 4:46 AM, Thomas Schwinge <tschwinge@gnu.org> wrote:
> > > Just a suggestion from someone who isn't actively using the ports
> > > repository: why not have separate Git repositories for each individual
> > > port, and base these repositories on the [glibc]/master branch? ?Doing
> > > so, the ports maintainers could periodically merge in [glibc]/master into
> > > their ports' branches (which may either be in a separate repository or in
> > > the main glibc repository), and it would also automatically be documented
> > > which port is maintained, which was the last version of [glibc]/master
> > > this port was tested with.
> >
> > I think this would be a great idea.
>
> I think it's just going to make more work for the maintainers of each
> individual port. Mostly, they just keep working. It'll also be a
> pain for multi-platform distributors like Debian, who will have to do
> the merge anyway.
I also think that would be massive overkill. Version control should make
common tasks easy and quick, and the most common task for ports is
updating ports copies of sysdeps files in agreement with the libc copies;
there's no need to add extra per-architecture merge steps to this.
Optimal would be not having the arbitrary distinction into ports/non-ports
architectures; removing the sysdeps files for non-Linux OSes for which the
support has long been dead (after all, version control allows them to be
recovered as needed) and for architectures noone has been maintaining
support for for a long time, and having target maintainers maintain
support for their architectures in the libc tree if the libc maintainers
don't want to update them when they make core libc changes. (libc
architectures don't always get updated anyway; just look at the SPARC
versions of sys/eventfd.h, sys/epoll.h and sys/inotify.h for examples.)
Given that we can't have that, a single ports tree is next best.
--
Joseph S. Myers
joseph@codesourcery.com