Retiring from uClibc development

[Peter S. Mazinger]

On Mon, 27 Mar 2006, Manuel Novoa III wrote:

> 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?)

Maybe I was too offending, sorry ...

> > 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.

I do not know what your expectations are, I had to touch all the files 
within uClibc (haven't counted them), I would want to see anyone not 
making failures by doing that and covering all the possible 
combinations/configs.
 
> 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.

If cvs/svn should be "stable", then stable branches are requested, as I 
understand it, the svn trunk version is for development, so anyone using 
it should does not expect stability (for that a release should be used)
 
> 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

One of the pet projects is called "buildroot", no current gcc will work 
correctly w/ svn, that's why I asked you to review it (the gcc-4.1.0 
patch tarball was splitted accordingly, so that you would have needed to 
read about 3 screens of diff -uN output)

> 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.

should buildroot remove support for all the non-working compilers?

> 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

My problem w/ you is, that I am finding conflicting files in "your" area, 
don't want to touch them w/o first asking, but you do not answer. What is 
the correct approach then? Should I change everything what I find as 
incorrect w/o asking, so you kill me?

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2