Retiring from uClibc development

[Peter S. Mazinger]

On Mon, 3 Apr 2006, Peter S. Mazinger wrote:

> Hello!
> 
> Please stop this thread. At the time I disabled my commit account to svn I 
> have sent an email to Erik, he will decide accordingly to 
> his/uClibc/community needs, if he enables it back or not (I proposed to 
> support uClibc, especially the changes introduced by me until at least 
> .29 comes out).
> 
> If his decision is to stop committing, then I will post my full diff of 
> my local changes to the ml and you are free to apply them or not.
> 
> Thanks, Peter

It's time to settle this after almost 2 months...

The only offer I have gotten (I have never gotten an email answer, it 
was only because I insisted on IRC) is to ask for approval for any commit 
I would want to do (sending the patch to ml and wait - probably waiting 
for months if at all getting an answer from the "official" developers)

I have decided not to go that path, I am not willing to wait for such 
approval (for months, as my emails weren't answered at all until now), 
any commit to svn can be undone, each developer gets a copy of it, so he 
can decide if he likes or not and it can be discussed, argued and svn is 
a development tree (in my view) not targetting any stability to users, if 
you "risk" to use it, then you have to live with failures, report them, 
provide patches and/or wait for solution.

I will provide a "working in progress, working for me on x86/ppc/arm 
little endian" patch against .28 to bugzilla (if bugzilla will accept 
such a large one, else I will send it to Erik and he should get it 
"published") that solves all the  uClibc internal problems I have came 
upon in the meantime, additionally it provides SuSv3 replacements for 
fnmatch/glob/regex (even getopt, although I know mjn3 won't like that), 
old linuxthreads updated to pass all the linuxthreads tests from glibc - 
additionally some of nptl - targetting the switch to NPTL as well), 
cancellation support being added to many functions required by SuSv3, all 
include/{,sys,bits} headers being synced with glibc and all functions not 
provided being disabled (TODO: first item), full SuSv3 math support (even 
long double implemented as wrapper as the float one), fenv related stuff 
for x86, option to disable old/deprecated features or non-SuSv3 features, 
the possibility to disable/enable hiding of symbols, disable use of the 
hidden_proto/_def/_weak options or build all libs w/ -Bsymbolic without 
any duplication - being the smallest possible - (handicap being that 
userspace apps won't be allowed to redefine any internal functions) ...

Maybe I have left some out of the enumeration, I have short-time-memory 
about what I have changed in almost 2 months since I have asked to 
reenable my account at least until .29 ...

After this I will start an own "uClibc-anyname" -I need a good name for it 
- (one of the first targets being to get rid of the duplication related to 
LFS/non-LFS versions of the functions, another one being to move 
non-SuSv3 functions into a separate "libcompat" library, currently 
working on the last release of linuxthreads getting to run w/ uClibc and 
getting ld-uClibc.so being smaller/faster).

It has to be an "own" version and not a branch, because I have to touch 
code that until now was untouchable due to respect to "old" uClibc 
developers (although they think I have done the opposite), because I 
can't rely on help from any of them and I have to touch code that I 
considered untouchable until now.

If anyone wants to provide a place for the new µC-anyname (svn would be 
preferred), please contact me.

Thanks for patience and reading up to this point, 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