Retiring from uClibc development

[Steven J. Hill]

Natanael Copa wrote:
> First, a big thank you for making uClibc and for making it available to  
> the public. Its awesome!
>
Your welcome.

> So, there are contributors, "competitors", that fix things and send 
> them  to you, motivated by the thought that as many as possible should 
> benefit  from it. You grab those fixes put them in your own private 
> space, keep  them there so no other can (easily) benefit from them until 
> you do  yourself?
>
I have no idea what your background is, but it would seem that you have
never done software contracting work before. It is a delicate balance to
develop OpenSource sofware and get paid for it. Those of us who get paid
to work on it, have to put the needs of our customers first before the
OSS community. The changes and fixes that are made for or supplied by
the company paying the $$$ belong to them until they decided they want
to release them, or they ship a product with the code in it. Whether you
like it or not, that is the reality and that does not violate OSS licenses
in any way. The downside is that we do get very busy and it gets difficult
to submit everything back, so some fixes do not make it back into the
tree as quick as some would like. It is not because we are being mean or
nasty. However, due to the contracts we do, we cannot simply say, "Well,
I do not have time to put these changes back. Here is my tarball of my
tree and someone else please put the changes in." Again, that may violate
our employer's request to keep fixes and enhancements private until they
say so. It cuts both ways.

> So while those (unpayed) contributors do what they can to help others  
> benefit from their work (by submitting fixes upstream instead of 
> running  their own branches, fork or whatever), you do what you can to 
> prevent, or  delay, others to benefit from it.
>
Branches are the issue here. Peter treated the trunk like his own personal
branch, which is not how things are supposed to be when you are touching
hundreds of files and adding new features....without testing it thoroughly.

> And I would love to see uclibc development move forward without being 
> held  back of buildroot or any other specific build environment or 
> distro,  without being held back for any specific company to release any 
> product  (which higly depends on market timing etc etc) and without 
> being held back  by any personal conflicts - but thats probably 
> unrealistic.
>
I think buildroot is very important, but I will let Manuel or Erik speak
up if they disagree with me. I have a perfect example for you. I have
spent 9-1/2 months of intense development bringing NPTL into uClibc. But
how do I test it? How do I know NPTL is really working and doing what it
should and doing it right? Testsuites. glibc has a wonderful set of tests
for testing hundreds of NPTL's internals to make sure it is right. That's
great, now I know NPTL is working. What about all the changes I made in
the C library and dynamic loader code for NPTL? I then use the uClibc
test suite to make sure all the other subsystems and system calls still
work. That is still not enough. All these tests were written for the
libraries themselves. Real world applications need to be tested. And that
is where buildroot comes into play. Now you are building a complete root
filesystem and running it on your board to see if things really all work
properly together. Now we have tested as much as we can and the code can
be taken and put into other distributions as anyone sees fit. Odds are
fairly good that uClibc is going to be rock solid. That is why I think
buildroot is an important component to keep working. My $0.50 worth.

-Steve