Re: glibc release management

[Cristian Gafton <gafton at redhat dot com>]

On Thu, 13 Jan 2000, Roland McGrath wrote:

> But these details of organization will get figured out easily enough
> when there are enough serious resources (paid hacker time) devoted to 
> getting libc done right.  Considering the current amount of support (such as I
> understand it), we are doing pretty damn well already.

While it is true that for Red Hat we do not have somebody doing 100% glibc
hacking, there are several people within the company that are hacking on
bits and pieces from glibc. I'll not get into specifics because this is
not a contest who has more people and doing what.

The problem is not really having that much developer time spent on it as
it is finding the right people willing to do the job. You need somebody
good at it, that Ulrich can trust. But maintaining the stable branch is
*boring*. There aren't that many people really willing to do the job (or
willing to do it full time and right).

It is hard to argue whether the current state of things is good or not.
Now bug-fixes get backported from the development branch, and sometime
this means that there are new features that have to be added to support
the bug fixes. One can argue that we could seek independent fixes for the
stable branch, thus introducing incompatibilities between the stable and
the development branch. There is really no clear cut to what's best.

I think we all need to exercise better judgement when recommending
patches for the stable branch. After all, Ulrich is overworked already and
he might sometime just trust somebody else when a certain bugfix is
recommended. If I remember right, it wasn't Ulrich that proposed the
setrlimit changes for glibc 2.1.3. Regardless of whether he bought or not
into that, we all need to exercise due care when talking about patching
glibc 2.1.x, Even if Ulrich maintains sole control over glibc, he needs to
have a number of peers that he can trust on recommending the right things
when it comes to the stable branch.

And there is one more thing - when we talk about the stable branch
sometimes there are differences between what the right thing to do is and
what is expected out of a distribution. The stable branch is used by
distributions. They depend on its stability and compatibility between
snapshots. I am all for doing changes in the developmenbt code "because it
is the right thing to do", but we have to bend the rules a little bit for
the stable branch, so that people working for the Linux companies on glibc
will actually work on *developing* glibc rather than continuosly hacking
on ways to revert incompatible changes, changed behaviors, stuff that make
the ISVs go crazy.

I don't know about SuSE (or others) but at Red Hat people working on glibc
are spending more time than they should tracking down fixes that break
applications, building wrappers and doing hacks to get stuff that used to
work running again. Now, I'd love to have these resources diverted to
actual development.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton    --     gafton@redhat.com     --       Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.