status of 0.9.30 release

[Rob Landley]

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_.

> 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.

> 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.

By current stable you mean a 0.9.29.1?

> That means 
> backporting bug fixes to the latest release as well as the development
> trunk. If that is handled correctly, there wouldn't be much of an
> issue about transitioning to 0.9.30 without linuxthreads.old as those
> requiring linuxthreads.old due to known stability wouldn't have to
> sacrifice development-driven bug fixes seen only on trunk.

You're welcome to do so.  (I was actually planning on doing this anyway, for 
0.9.30 with linuxthread.old removed.  But I'm not going to be ordered to do 
so by somebody else.)

> Because that is not possible today without quite an effort to track
> down all the bug fixes in the past 8 months (since the last change to
> the 0.9.29 branch),

There's a 0.9.29 branch in the source control system?  (I never look at svn 
branches.  I look at multiple git or mercurial trees, but trying to 
coordinate two different svn branches is too much like work.)

> I would recommend leaving linuxthreads.old in 
> uClibc.

Let me put it this way:

I'm interested in stabilizing the new linuxthreads.  I'm not interested in 
trying to keep two linuxthreads forks in sync in the same release.  If 
stabilizing the new linuxthreads involves doing that, I'm not interested in 
putting any effort into it.

> I know it may depress testing and bug reports against the new 
> stack,

Yes!

> but to post a "stable" version that is known not to be 
> completely tested just to spur testing is backwards.

It's not known not to be completely tested.  If you know something it does 
wrong, I want you to tell me, so I can fix it.

You're arguing that it _may_ not work with your load, but you don't know 
because you haven't tried it.  This will NEVER get fixed until the old one 
goes away.

> We need to 
> inspire more confidence in the stability of the package, especially
> since every part of a system depends on the C library functioning
> correctly.

And until you're convinced it's stable, you won't even look at it.  How is 
this my problem?

> >> Also, I posted a patch to rectify a pthread fork mutex issue for
> >> linuxthreads.old. I am not convinced that the newer linuxthreads
> >> stack
> >> safely deals with the situation either, so porting that patch may be
> >> wise. It shouldn't take hardly any work to do so as well.
> >
> > I'm guessing you're referring to:
> > http://uclibc.org/lists/uclibc/2008-September/020110.html
> >
> > And yes, I'd like to have this discussion about the new linuxthreads.
> >
> > Possibly I should look for all svn commits to the old linuxthreads
> > and see
> > which ones are needed in the new one.  I'll add it to the todo heap...
>
> That fix hasn't been committed anywhere yet, so you'll have to base
> off of the patch I posted.

Happy to do so (when I get that far down on my todo list), but I'm only _ever_ 
going to be committing fixes to the new one.

> Thanks,
> Chase Douglas

Rob