Re: status of 0.9.30 release

[Chase Douglas]

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

before contemplating getting right of the older linuxthreads stack.

openssh can compile against uClibc with the newer 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.

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


My point is that having another release containing two pthreads

I just don't want _both_.

I.E. you seem to have no intention of even trying to use the new one until the 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.) implementations is _stupid_. I'm not strongly attached to _either_ of them,

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.

year and change of new development went in all over the place.


deploying.

The flaw in your reasoning is that 0.9.30 is not a bugfix-only release. A 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

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.

history of open source development that I'm aware of.

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

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?

Thanks,
Chase Douglas

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.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc