Now I'm curious...

[Kevin Day]

On 9/3/07, Ricard Wanderlof <ricard.wanderlof at axis.com> wrote:
>
> On Mon, 3 Sep 2007, Denys Vlasenko wrote:
>
> > ...
> > The truth is, stability and development are mutually exclusive, if you want
> > more stability, you inevitably lose some development speed.
> > And this is exactly what happened.
> > ...
> > We can decide to allow more unstable uclibc svn head, with the agreement
> > that when it will be decided to do a release, we will have x.x.0 unstable
> > and people will work on fixing on the regressions for x.x.1, x.x.2,
> > _especially_ on the regressions caused by *their* changes.
> >
> > Between releases, people who need stable uclibc will use last stable
> > release, and add bugfixes for that release to it's own stable branch.
>
> I second this. I think part of the problem was that releases have been
> further and further apart, and 0.9.28 was more bug-ridden than was
> comfortable, leading to a need for having a stable svn head just to be
> able to get something up-to-date which was still reasonably stable.
>
> I think with the introduction of 0.9.29, and a potential 0.9.29.1 not
> being to far down the road should the need arise, this fear of a non
> stable head should be significantly reduced.
>
> (I don't know if there's been some sort of parallel with buildroot
> development, where the svn head really is the latest release. This is a
> different case though as buildroot is not a library we need to trust, just
> a collection of stuff put together in a practical way.)
>
> /Ricard


Except for:
1)  There is no stable uClibc, 0.9.28 is bugridden, 0.9.29 requires a
number of patches only available in svn (let alone countless other
bugs yet to be publicized) , and releases prior to 0.9.28 seem to have
a history of "your not using the latest version, please update" or
something along that line.

2) There has been more development going on than bugfixing and when
development slowed down, bugfixing also has slowed down.

3) For better or _worse_, gcc is the compiler to use. They have a
system where many bugfixes are released in later versions that have
features and other changes applied.  These features / other changes
end up breaking something else and making the bugfix system rather
pointless.  Now add an already unstable libc and mix it with gcc.
This only makes things worse. The current development pattern uClibc
is following is very similar in that a number of bugfixes were applied
to 0.9.29 that fixed bugs in 0.9.28; however,  in addition to those
bugfixes, there have been significant code restructuring and feature
additions.

I can see no reason why you should so much as think about starting a
new version of uClibc with a completely new (and eventually better)
threading system.  The very foundation of the project is virtually
non-existent, let alone sound. There will be countless bugs and
problems as a result of building a threading model with such an
unstable base to start with.

Many people may want the new threading method, but I also imagine they
want the machine to not segfault, memory leak, and otherwise crash
every two minutes.  Stabilize your code base, stop changing that code
base, and then build the new threading method, so that the only
differences between uClibc 0.9.29.* and uClibc 0.9.30 is _only_ the
threading rewrites. This way, the only problems that occur will be of
a direct result of the threading changes and not some obscure problem
that is almost impossible to find/identify.

Here, gcc's inability to create a stable code base makes for a code
bug-testing ground for uClibc.  If uClibc can compile a complete
system under gcc-3.4.6, gcc-4.1.2, and gcc-4.2.0. without any patches,
hacks, or other tweaks whatsoever (to uClibc). If the system runs with
no hitches under all 3 gcc's, then uClibc will probably be pretty
stable. This includes all supported architectures. As of right now, I
know this is not possible.


At the very list, if you say that there is a stable version going on,
make it actually happen and use gcc as an example of what not to do.


-- 
Kevin Day