This is the mail archive of the 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]
Other format: [Raw text]

Re: Latest Glibc from CVS has segmentation problems.

At 07 Mar 2004 10:56:54 -0500,
Patrick J. LoPresti wrote:
> > In my opinion, it is not the responsibility of the maintainer to be
> > the support guy for everybody.
> I am not claiming his responsibility includes supporting anybody!  But
> he goes beyond not providing support.  He tells newbies "you are a
> random person and therefore should not be compiling glibc", which is
> absurd.

I am hopeful that if somebody would make a serious effort to guide
newbies around glibc, we could get him to say something like
"", which is shorter.  When there is no such
effort, however, the best advise to give lost people is to not bother
trying, so they know that they are on their own.

> And his responsibility does include making releases, doesn't it?

I don't know what's holding up a glibc release, so I can't tell.  I
can think of a zillion (generic) reasons not to make a release,

One easy thing would be to ask, in a new thread, and without
prejudice, "What must happen or be done before a release can be done,
and is there any way I can help with that?".  Such a question might
still be ignored, however, because usually release schedules are not
discussed with "random people".

Usually, software is released if you want to get people to use a
particular version of the software.  With glibc, things are in so far
different as it is _always_ included in _all_ distributions, and you
can't simply update it.  It's quite unlike an application software
package.  If you look at the versions of glibc distributions actually
do include, you will quickly find out that they have nothing to do
with glibc point releases whatsoever, so the question arises how
meaningful and/or useful such a point release is.  Under such
circumstances, I'd personally also only make a release if there is a
particular reason (for example, a new stage in development has been
reached, and you make a release before doing other fundamental

However, that's just my rambling.  What the real reasons are for glibc
I don't know.

Nothing stops you from making your own glibc releases from CVS
versions and release them under version names similar to Alan Cox's
experimental Linux kernels.  Maybe by doing that you will find your
own reasons why glibc is not released officially at this stage...


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