Re: Roles for distributions

Hi,

quoted

There has to be someone there who can at least make builds, file bug
reports, and point out when things are broken.  Even that would be a big
help.  I filed a make check report with the glibc maintainers and basicaly
got back a "we are not interested, fix it yourself if you want it fixed".
That generally doesn't happen if someone from ppc is contributing in some
way to the project.  Luckily, some of the other glibc developers chimed in
to rephrase the reply.

Well, first of all, that's not a general project thing - that's Ulrich
Drepper's attitude problem.

Secondly, bug reports filed by someone who can just make and make check
are not terribly useful - no one really has time to dig.  We need
people who can file bug reports with analysis, and not many people can.

Here is the only point I disagree with.  As a volunteer, I don't even know
if a project needs my help.  The only reason I started testing glibc 2.2
was that there was some noises that it was nearing release and almost every
time glibc comes out it breaks something for native threads which are
really needed by the jdk.

If people regularly do builds, and do "make check" then errors will appear
near in time to recent patches and things (sort of like Linus's only give
me small patches approach) that can tell the maintainers that something is
amiss.  That makes any bugs much easier to find.  My last glibc 2.1.3 patch
was found by doing regular builds to compare different glibc releases and
it was easy to see that Ulrich's post 2.1.3 release breakage was the
culprit.

I can't help fix things if I don't know its broken.  That is why people
doing regular builds, even if that aren't as skilled as Dan, or David, or
Gary or Franz would surely help.

Kevin

--
Kevin B. Hendricks, Associate Professor of Operations and Information
Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 21:04 11.09.00, Hendricks, Kevin wrote:

If people regularly do builds, and do "make check" then errors will appear
near in time to recent patches and things (sort of like Linus's only give
me small patches approach) that can tell the maintainers that something is
amiss.  That makes any bugs much easier to find.  My last glibc 2.1.3 patch
was found by doing regular builds to compare different glibc releases and
it was easy to see that Ulrich's post 2.1.3 release breakage was the
culprit.

I can't help fix things if I don't know its broken.  That is why people
doing regular builds, even if that aren't as skilled as Dan, or David, or
Gary or Franz would surely help.

Actually the really time consuming part is hunting down the bugs, but
regular builds certainly help to narrow down the time a bug happened "it
passed all the tests yesterday, but today it fails test XYZ". I doing
nearly daily builds of the GCC mainline, and sporadic builds of binutils
(which usually remains stable for Linux/PPC currently) and glibc (where the
2.1 branch is more or less dead, and the 2.2 stuff slowly reaches stability).

Bug hunting is usually quite easy for bugs during "make check", the really
nasty stuff are things like "program XYZ doesn't behave like before if run
on glibc-2.2", especially if a lot of large shared libraries are involved.
Eg. I have now spent 3 or 4 evenings trying to track down the "gdm doesn't
work on a xf4 compiled against glibc-2.2 headers" reported by Jack, easily
reproducible with the gtk+ "tree" example running as root. Still I didn't
get to far tracking the bug down, cause I'm wading in megabytes of xf4 and
gtk+ code, I nearly know nothing about :-(. It "feels" like a bug in
glibc's str*/mem* macros/functions, but I haven't got to a point where I
can observe the bug and act on it.
_That_ is the most annoying part where some help is most welcome :-).
Unfortunately it requires quite some knowledge :-( and the ability to cope
with using beta software for main components like glibc.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/