This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |