Retiring from uClibc development

Steven J. Hill sjhill at realitydiluted.com
Mon Apr 3 02:01:42 UTC 2006


Rob Landley wrote:
> 
>>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.
> 
> Disturbing trend.
>
Careful of your hypocrisy my friend. I know d*** well how things work at
TimeSys. They have patches that are not released to the general community
because customers have requested that they do not or that they are delayed.
It is no different than what I am doing for NPTL or what Manuel is doing in
his private tree. If a customer is paying, like it or not, you are ethicly
bound to fulfill their wishes.

> Query: is there going to be a 0.9.29 release?  If the objection is that psm 
> was destabilizing a tree that's trying to be cleaned up for a release, that's 
> an understandable objection.  If the objection is that uClibc is expected to 
> have every daily snapshot work because it no longer cuts releases (ala 
> buildroot), and using the last released version is no longer really a viable 
> option anymore, that's not really a very appealing model.
> 
Let me spell this out for everyone, for the....oh...I don't know, about the
10th time I think. I do not expect buildroot to be buildable and correct
every single day of the week. That is unrealistic. What I do expect is that
if someone wants to commit code and the code are large feature changes or
touches a lot of files, that they do it in their own branch first. Next, they
should ask people on the list to check out their branch and test it before
committing any code. Once approved, it can be put to the trunk. What should
have happened was that Peter should have been given his own branch to start
with and been asked to work there for a while to prove himself. That is the
whole problem and why this thread has gone on. We want more developers for
uClibc. We do not want sloppy developers running amok in the main trunk. We
want people to follow a process of working in a branch, testing and then
committing. buildroot should build completely with your new feature addition
or touching of a ton of files. That is not too much to ask. If you cannot
abide by those rules, then you post patches to the mailing list and you
should not have commit access. Hopefully this should clear things up. I do
not how to make it any simpler.

-Steve



More information about the uClibc mailing list