glibc standards discussion
I've been "listening" to the discussion on 2.0.7 glibc, and the
difficulties seem to stem from the fact that this product is not stable
yet, even after "release". Some of this is a release management problem,
but the main problem is the main problem with Linux in general, it is
still a moving target. That presents us with a problem of tactics.
I would suggest we take the same approach that is being suggested for the
whole standard. Start small and build on success.
With libc we should start with useful subsets of the "user space"
functions that I can create benchmark test routines that will validate the
specified functionality. Once we can "prove" implimentability of these
features in an existing library, the specification can push further into
the function space of the library. How far such advances can be made will
depend on how quickly those parts will stabalize. By providing a test
bench for the glibc developers, we can hold the ground gained by the
standard while we push for stability in other areas.
It is my feeling at this point (from my experiences with Ulrich and
packaging glibc for Debian) that 2.0.x is in the final stages of
completion (that terrible last 10%) where you push down one bump and it
crops up somewhere else. Having a good test bench for the "fixed" portions
of the problem space allow you to keep the bumps from occuring in what you
have already fixed, and the work can proceed to completion.
What I am saying, in my longwinded fashion, is that we can help guide the
stability of these "developing" libraries by producing a growing standard
with adequate test proceedures, providing tools the developers currently
lack that they desparately need.
Thoughts?
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: