This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linux vs. libio



  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]