Retiring from uClibc development

[Manuel Novoa III]

Peter,

On Thu, Mar 30, 2006 at 10:30:44AM +0200, Peter S. Mazinger wrote:
> On Wed, 29 Mar 2006, Manuel Novoa III wrote:
> 
> If you consider locales defective/not working correctly, removing support 
> for them would get rid of much of (at least for me, "untouchable") code.

Wish I knew what your definition of "untouchable" was.  Anyway, the
locale support was a proof-of-concept.  While I would like to see it
rewritten, that doesn't mean we should rip it out.  I know that there
are people using it.

> How do you feel then about internals changing to use UTF8 exclusively, 
> getting rid of the TABLES*/CTYPE*/WCHAR and such config options?

Why?  The whole point is to provide options.  The majority of devices
runing uClibc are not desktop systems with lots of ram.  Sometimes
every little bit helps.

> > > 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."
> 
> see for ex. buildroot/toolchain/gcc/4.2.0/203*, that is wide character 
> related as well, not only locales and is related to all gcc versions used 
> (the oldest checked is 3.3.5, probably all 3.3.x)

I need to build a new 3.3.6-based toolchain this weekend.  I'll look at
it then... along with a number of other patches that I spent last
weekend collecting.  I'm not the only one who hasn't been maintaining
the toolchains in buildrooot...

> > 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)
> 
> good to know that sometime a fix will come out ;-(

Of course they will.  What did you think?

> > 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.
> 
> I don't have such limitations, I am/was not payed for any of my uClibc 
> work.

There's a lot of work I've done on uClibc and busybox that I wasn't paid
to do either.  But I'm far less inclined to hand out free lunches these
days, for reasons I'll go into in my next post to this thread.

Manuel