status of 0.9.30 release

Chase Douglas cndougla at us.ibm.com
Sun Sep 28 03:38:14 UTC 2008


On Sep 27, 2008, at 10:39 PM, Rob Landley wrote:
> On Saturday 27 September 2008 18:42:33 Chase Douglas wrote:
>> On Sep 27, 2008, at 6:09 PM, Rob Landley wrote:
>>> On Friday 26 September 2008 10:06:22 Chase Douglas wrote:
>>>> Has anyone else tried to compile openssh against the new  
>>>> linuxthreads
>>>> stack? When I tried a few weeks ago it failed to compile auth- 
>>>> pam.c.
>>>> In that file they do some pretty wacky stuff like redefining some  
>>>> of
>>>> the pthread functions. Unfortunately, there doesn't seem to be a  
>>>> way
>>>> to get that file to build due to the way the uClibc pthread header
>>>> files are architected. So my suggestion would be to make sure that
>>>> openssh can compile against uClibc with the newer linuxthreads  
>>>> stack
>>>> before contemplating getting right of the older linuxthreads stack.
>>>
>>> See, this is exactly the sort of bug report we _don't_ get unless we
>>> at least
>>> threaten to make the old one go away.
>>>
>>> At this point, it's been so long since 0.9.29 shipped that 0.9.30 is
>>> going to
>>> need a 0.9.30.1 fairly promptly, from the bug reports of people who
>>> don't try
>>> it until it ships and then find some regression snuck in over the
>>> past year
>>> and a half.  We can't avoid it, we should just face up to it.
>>>
>>> Getting as many people as possible to test it before we ship is of
>>> course
>>> vital.  (Mentioning -rc1 on the uClibc website might be a good idea,
>>> but the
>>> website seems to have moved out of the main archive and I have no
>>> interest in
>>> tracking down where it went.)
>>
>> I understand your reasoning for trying to remove the linuxthreads.old
>> stack. However, I see an issue with this approach in that there are
>> users who depend on a "stable" release to be stable, within a margin
>> of error. Removing the only known stable stack, as in well tested in
>> many environments, does not inspire confidence in the reliability of
>> "stable" releases.
>
> I.E. you seem to have no intention of even trying to use the new one  
> until the
> old one goes away.  How exactly is this arguing against my position?
>
> The obvious alternative is to delete the other one, by the way.  I you
> honestly believe that LINUXTREADS_OLD is the only threading stack  
> people ever
> use, and the other one was a mistake, I can start advocating the  
> removal of
> the newer one.  (Presumably it'll all eventually be replaced by NPTL  
> anyway.)
>
> My point is that having another release containing two pthreads
> implementations is _stupid_.  I'm not strongly attached to _either_  
> of them,
> I just don't want _both_.

There are two types of end users of open source packages. There are  
those who are eager to install the latest code and work with it to  
make it better. Those users are highly desirable for open source  
projects as they are what drives development. However, a second type  
of users also exist: those that are under fixed budgets in terms of  
time, effort, and/or monetary resources. These users may not have the  
ability to vet code in this way and require a reasonably stable base  
package to even think about using it. It's perfectly fine to say that  
uClibc is only geared towards those that have the resources and are  
willing to spend them on verification testing before using it.  
However, I am under the impression that the goal of uClibc is to have  
stable releases that should work on their own without the end user  
having to perform such testing.

If that isn't the goal, then feel free to function as you see fit in  
pursuit of the goals you have in mind. I am not trying to dictate  
anything to anyone as this is an open source project. I understand how  
work actually is performed on these types of projects. Please  
interpret my posts as suggestions and not ultimatums.

>> If one needs a truly stable uClibc, you're
>> basically telling people not to rely on 0.9.30, at least until
>> 0.9.30.1. That leaves users in a tough spot because the last "stable"
>> release was way back in May of 2007. A ton of bug fixes have entered
>> the tree since then leaving users the impression that 0.9.29 isn't
>> really "stable" anymore.
>
> The flaw in your reasoning is that 0.9.30 is not a bugfix-only  
> release.  A
> year and change of new development went in all over the place.
>
> Moving from 0.9.29 could break _anything_ for you.  We'll test it  
> the best we
> can, but only you can tell us whether it works for your data set.   
> This issue
> is not specific to threads.  Chosing to move to a new codebase is  
> something
> you have to schedule, and which you need to do your own testing for  
> before
> deploying.

I understand what you are saying completely. However, I believe it  
makes sense to offer users the choice: the new version which we  
believe to be reasonably stable, or the previous version with all the  
fixes we've found since it was released. Right now I'm left with the  
choice of the previous release without any fixes since it was  
released, or the very latest release (when it comes out) which  
probably isn't as stable as the previous release with all the fixes.  
It's the same reason server distros never ship with the latest kernel  
version available. Such users need a history of use before a given  
version is considered stable enough for such use.

>> What I propose is that uClibc actually maintain the stable branches  
>> of
>> uClibc, at least the current stable release if not more.
>
> Ah, the old "I vote to have other people spontaneously volunteer to  
> do X"
> ploy.  As popular as ever, despite never actually having worked once  
> in the
> history of open source development that I'm aware of.

I'm sorry. I'll keep my suggestions and thoughts to myself next time  
instead of letting others hear them. :)

I'm just proposing possible solutions. I don't know what time is  
available from developers to be able to carry them out. It's perfectly  
fine to say that the resources just aren't available for such  
endeavors. However, dismissing suggestions outright certainly doesn't  
help.

> By current stable you mean a 0.9.29.1?

I've not seen any mention of 0.9.29.1 anywhere. It's not available for  
download and I don't see any svn tags for it. Where can I find it?

I'll sum up the reset of the conversation as follows: First, I should  
have been a tad bit more clear when I said I thought linuxthreads.old  
should be left in uClibc. I was meaning that it should be left in  
0.9.30 until a good 0.9.30-fixes branch is established alongside a  
future version that has linuxthreads.old stripped out. That would  
provide ample time for people to realize that linuxthreads.old is dead  
and will only be maintained in 0.9.30 until 0.9.31 is out.

Again, feel free to disregard this approach due to resources  
available. I have no issue with that.

Second, You have stated that you don't care necessarily which  
linuxthreads implementation is kept, just that only one is. However,  
you seem eager to throw out linuxthreads.old, which I thought was more  
stable, in favor of the newer stack. Especially given that uClibc is  
supposed to be getting nptl support soon, obsoleting both linuxthreads  
implementations, why force the change to the newer stack for this  
short period? If any of these statements are wrong, feel free to  
disregard.

Thanks,
Chase Douglas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3892 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20080927/2ec21ed9/attachment-0002.bin 


More information about the uClibc mailing list