Retiring from uClibc development

Manuel Novoa III mjn3 at codepoet.org
Thu Mar 30 02:54:24 UTC 2006


Peter,

On Thu, Mar 30, 2006 at 01:03:18AM +0200, Peter S. Mazinger wrote:
> On Mon, 27 Mar 2006, Manuel Novoa III wrote:
> 
> 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)

Indeed, svn trunk is for development.  But you have to consider the
other developers as well.  sjhill is making widespread changes to the
lib... but in his own branch.  In the past, I've rewritten entire
subsystems in my own tree and then checked them in as a unit.  Erik
has done similar.  But right now, sjhill is having problems dealing
with the excessive churn in svn and neither Erik or I are even using
it.  We all use uClibc for "work" and need a certain level of
auditability.  That's one reason why single commits of a group of
logically connected changes is preferred.

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

I never added any of the gcc's >= 4.x.  I didn't even add some of the
3.4.x's.  Same goes for the newer binutils.  The only thing I did do
was try to clean up a bit the 4.0.0 checkin originally done by sjhill.
I'm not even using current buildroot.  I took a snapshot months ago
and have been using that.  The locale support change for 4.1.0 I did
as a favor and didn't get to spend as much time on it as I wanted.
I plan to look at it again this week or this weekend.  But I've got
quite a few coverity defect reports for uClibc to work through this
week too.

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

Should I spend my _own_ time supporting tools in buildroot that I'm not
using and didn't even add in the first place?  Especially given the
almost total non-response to the request in my dedication file and the
almost total non-response to similar requests when I spent 2 full-time
months after Toni's death working on busybox and contributed that in
her name?  BAH!

I'm happy to work on things if contracted... be that for pay or in
exchange for charitable donations to hospice.  But I did my bit of
contributing large amounts of my own time and essentially got slapped
in the face for it.  I'd rather spend that time (what little there is
of it these days) with my wife or working on something that interests me.

> > 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.
> 
> My problem w/ you is, that I am finding conflicting files in "your" area, 

Not sure what you mean by "my area" or "conflicting files".  Regarding
the latter, if you're talking about those locale defines you emailed
me about a while ago, I don't care.  I'm not currently using locales and
really don't plan to support the current code unless contracted to.

In fact, I might not even take a contract to support it if someone offered
one because I consider supporting something that needs extensive rewriting
to be counterproductive.  I would however take a contract to do the
necessary reimplementation.  If I wind up doing it outside of a contract,
I'd likely make it a seperate GPL'd lib with a provision to relicense
as LGPL.  At least that way, companies using uClibc might have more of a
reason to contribute something back in the way of support.

> don't want to touch them w/o first asking, but you do not answer. What is 

If you're asking about anything related to newer toolchains I'm not using,
issues resulting from your hidden symbol support changes, or from the IMA
compilation stuff, the general answer is "I'm not  currently using that it."

> the correct approach then? Should I change everything what I find as 
> incorrect w/o asking, so you kill me?

On the other hand, if you've got a bug report not specific to your branch,
tell me and I'll fix it in my tree.  I already have several fixes there for
problems that you and vapier have reported to me.  When we (i.e. my employer)
release something using the updated version, I'll make thoses fixes available.
But I'm generally not going to make fixes available to our competitors before
we actually roll them out ourselves.

Manuel




More information about the uClibc mailing list