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]

Re: glibc release management



Hi,

On Fri, Jan 14, Cristian Gafton wrote:

> 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).

I think this is the result from having only a few people really working
on glibc. If we could find more people who would work on glibc, it should
be much simpler to find one who is good enough and willing to do the job.


[...]

> 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

No, it was Ulrich who add the setrlimit changes for glibc 2.1.3. After
this breaks a lot of appplications and architectures, Ulrichs comment
to me was "we need it" and Andreas Schwab and I tried to fix it.

[...]

> 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.

C++ (the various libstdc++ versions) to maintain makes much more trouble
then glibc. Often it is not enough to copy this versions from an
older release, you need to recompile them with special hacks.

Ok, SuSE avoided glibc 2.1 and started with glibc 2.1.1, but with the
step to glibc 2.1.2 we have only one real problem with linuxthreads.
This is less then I expect, but more then should.

With glibc 2.1.3 the current situation is more worse. Not from
binary compatiblity, but there are far to much patches which breaks
to many other plattforms.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/       kukuk@suse.de
SuSE GmbH            Schanzaeckerstr. 10            90443 Nuernberg
Linux is like a Vorlon.  It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

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