This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: Linux vs. libio
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Linux vs. libio
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 20 Dec 1999 17:11:12 -0700
- cc: jlarmour at cygnus dot co dot uk, gcc at gcc dot gnu dot org, libc-alpha at sourceware dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <19991220152927Y.mitchell@codesourcery.com>you write:
> If that's what the steering committee, or whoever decides this kind of
> thing, wants to do, then that's what we'll do.
A branch is certainly the direction I'm leaning.
> But, I think it's really not a good idea.
>
> In practice, this will lead to a lot less testing.
But it will avoid diverging our libio sources unnecessarily, which reduces our
development/support burden.
You have no idea (nor does anyone else right now) when the next release cycle
will start. We don't need the extra burden of forcing the release manager to
pull your code out of the mainline sources because it wasn't finished, or the
glibc folks decided to go a different direction, etc etc.
Until such time as you've got a buy-in from the glibc folks you need to either
keep the code private or work from a branch.
> Doing the new ABI work has already spotted bugs in the compiler, and
> requires various other cleanups. We'll lose those advantages in the
> mainline, and there will be semi-serious divergence.
Just like the new ia32 port, garbage collection and new fixinclues did. But
ultimately doing it on a branch was the right thing to do in each of those
cases. I believe we're in a similar situation now -- from a maintenance
standpoint (as opposed to a stability standpoint).
> We (CodeSourcery) might not have the resources to do the merge which
> might mean the community may be unable to profit from the new ABI
> until someone volunteers to do it.
That's the chance you and everyone must take when they decide to work with
free software projects. If you don't have the resources to do the merge, then
you (in reality) under-bid the work by under-estimating the integration
aspects of the contract. I problem I am unfortunately all too familiar with.
> Think how long the GC work done on
> the branch by Bernd and Richard might have languished had we not
> stepped in to integrate it.
Yes. I'm well aware of that. Again, that's the chance you have to take to
play the free software game. Note that the GC work was done entirely without
a customer and thus had nothing to drive it to completion.
> o We're not going to break IA32 Linux.
This isn't the issue.
> o We're not going to do stuff willy-nilly without asking the libio
> folks for approval.
This is the issue. And I've stated before that if you get a buy-in from
the glibc folks then you can go forward. But you need a buy in *before*
you start checking in the changes.
> What's happenning here is that we're doing open development.
And you can just as easily do open development on a branch. You can even
use the branch for highly experimental work to get it to a point where you
and the glibc folks agree on the general direction.
jeff