creating glibc-ports CVS repository?

creating glibc-ports CVS repository?

[Alexandre Oliva]

glibc has recently been added some infrastructure to support drop-in
add-on ports.  The first such port I'm aware of is the am33/2.0 port.
I suspect the mips port may soon be required to move out of glibc,
since it doesn't even build.  I'd like to soon contribute an frv port
as well.

I was thinking we might be able to maintain them in the glibc CVS
repository, but, erhm, some recent developments made me think this
isn't going to work :-)

So I'm thinking it would be nice to create a separate CVS repository,
perhaps with its own mailing list and, perhaps, a home page.  Could we
have this set up?  I volunteer to be the project maintainer for the
time being.  I hope other maintainers of ports that can't make it to
the main glibc tree, or that get pushed out of that tree, join this
project and maintain their ports in this separate repository.

What's the procedure to get such a new project added to s.r.c?

Thanks,

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: creating glibc-ports CVS repository?

[Ian Lance Taylor]

Alexandre Oliva <aoliva@redhat.com> writes:

> glibc has recently been added some infrastructure to support drop-in
> add-on ports.  The first such port I'm aware of is the am33/2.0 port.
> I suspect the mips port may soon be required to move out of glibc,
> since it doesn't even build.  I'd like to soon contribute an frv port
> as well.
> 
> I was thinking we might be able to maintain them in the glibc CVS
> repository, but, erhm, some recent developments made me think this
> isn't going to work :-)
> 
> So I'm thinking it would be nice to create a separate CVS repository,
> perhaps with its own mailing list and, perhaps, a home page.  Could we
> have this set up?  I volunteer to be the project maintainer for the
> time being.  I hope other maintainers of ports that can't make it to
> the main glibc tree, or that get pushed out of that tree, join this
> project and maintain their ports in this separate repository.
> 
> What's the procedure to get such a new project added to s.r.c?

Call me crazy, but I think the right place for glibc ports is the
glibc repository.  That seems like the best way to keep them
consistent.

I think the only other reasonable alternative is to fork glibc as a
whole.

Ian

Re: creating glibc-ports CVS repository?

[Alexandre Oliva]

On Jul 17, 2004, Ian Lance Taylor <ian@airs.com> wrote:

> Call me crazy, but I think the right place for glibc ports is the
> glibc repository.

The maintainers have already made it clear that they don't want that,
except for ports that are maintained by the core glibc maintainers
themselves.

> That seems like the best way to keep them consistent.

They don't want to care about keeping them consistent.  They don't
want to have to worry about other random ports when making changes.
This sounds perfectly reasonable to me.  It's up to the port
maintainer to keep up with global changes.  But I suppose they don't
want the ports in the tree, because it would make cvs updates slightly
slower, would make the tarballs bigger, and would probably get people
to blame them for shipping glibc releases with broken ports.  This all
makes sense to me. 

So the idea of maintaining ports in separate trees came up.  I
actually support the idea of pushing ports that are not very actively
maintained out of the main glibc tree.  The maintainer of the port is
then responsible for not only keeping the port up to date, but also
releasing the port in such a way that it works with particular glibc
releases.  It's not fair to demand of the global glibc maintainers to
maintain ports they have no interest in maintaining.

> I think the only other reasonable alternative is to fork glibc as a
> whole.

For every add-on port?  This sounds like a lot of overhead for little
to no gain.

Since the idea of handling add-on ports as CVS modules, or even to
make them part of the glibc CVS repository, were all rejected, I think
creating a separate tree for add-on ports is what makes the most
sense.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}