Retiring from uClibc development

[Manuel Novoa III]

Peter,

On Mon, Mar 27, 2006 at 11:09:24PM +0200, Peter S. Mazinger wrote:
> Hello or good bye!
> 
> My experience of being an uClibc developer:
> 
> Don't get in conflict w/ another developer ...
> 
> I am tired of argueing (is this correct english?)
> 
> I had to "run" 2 conflicting situations:
> 
> mjn3: He contributed much of the stdio/string/wchar/locale code, but 
> currently does not contribute due to other responsibilities. My problem 
> was that while he is not doing anything for uClibc, he is not willing/able 
> to help solving problems that are directly connected to his own code, even 
> ignoring patches that need "OK" to commit
> I know that he disliked the way I splitted libc/string, I would have 
> splitted all the others needing this (ctype/wchar/...), but haven't dared 
> doing it, now uClibc will have to live w/ dummy .c files that include some 
> other .c.

My primary disagreement with you is that you were making widespread changes
in tip in a piecemeal fashion, intermixed with bug fixes, feature additions,
etc.  This made svn tip for me almost useless, because I _have_ to have
something reasonably stable for my work.  So as I told you several weeks
ago on irc, I was forced to maintain my own tree based on the 0.9.28 release
where I've continued development.

In the years Erik and I have worked on uClibc, widespread changes were
made in our own trees, tested, and then merged back into the main tree.
This helped us not step on each others toes and also helped us keep cvs
in a state where we could use it for ourselves and, more importantly,
our _customers_.  I would have had no problems if you had worked in a
similar fashion, and only merged in library-wide changes as a unit.  But
instead, you essentially treated svn tip as your own private branch.  If
we were using uClibc completely as a hobby, this would be less of a
problem.  But with the work-related constraints I'm under, the only use
I had for svn was cherry-picking bug fixes... a job made more difficult
and time consuming by the noise in the logs genertated by your multiple
commmits per file intermixed with actual bug fixes.

In short, I've simply treated svn tip as your branch and avoiding looking
at it until some future time when it was stable.

> sjhill: working on an uClibc branch and being "disturbed" by my changes
> to uClibc trunk (he "catched" a "wrong" "stable" state, after that 
> almost everything was rewritten by me to get smaller uClibc and add some 
> security related issues)
> (uClibc's libc.so really has gotten smaller by the way.)
>
> I am tired to accept that anymore and disabled my svn account. I can't 
> work w/ ppl, who are not providing any help, the only reaction being 
> telling me that something is wrong, but not providing any help.
> They all are right and me failing ...

Again... the point is that you shouldn't have been making widespread
changes to TRUNK until you had something stable to merge from your
own branch, which could have gone in as a logical unit.  But the way
you've worked with tip has made it more difficult for the rest of us
_and_ cost us time.  You talk about us not working with you.  But I
honestly can't see _how_ I could work with you unless you changed the
way you used svn.

> I have sent "preliminary" patches to mjn3 for "approval". Result: gcc-4.1 
> has gotten faulty patches in buildroot ignoring my proposals
> 
> sjhill was "seen" in the earlier discussions: good luck w/ gettext ...
> 
> Peter

Sorry if you want to get your nose out of joint.  But I really don't have
time right now to take in interest in your pet projects.  Nor do I have
much time to put into looking at tool versions I'm not even _planning_ to
use in the short term, much less right now.  I did a quick hack for gcc-4.1,
which I did say was untested, for sjhill and erik.  But I'm not currently
using _any_ of the 4.x compilers for work purposes.

Also realize that I haven't stopped my own development for uClibc.  It just
takes place in my own tree.  When we release something linked with it, the
patches will be made available and integrated.  But I can't ethicly (at
least in my code of ethics) justify handing out bug fixes to my employer's
competitors until necessary.

Manuel