Retiring from uClibc development

[Jan-Benedict Glaw]

On Sat, 2006-04-01 13:40:33 -0700, Manuel Novoa III <mjn3 at codepoet.org> wrote:
> On Sat, Apr 01, 2006 at 02:41:42PM -0500, Rob Landley wrote:
> > On Thursday 30 March 2006 11:54 pm, Manuel Novoa III wrote:
> > But every time I hear somebody trying to discourage a volunteer because their 
> > work makes life difficult for people trying to get paid for the same sort of 
> > work, I _automatically_ discount that argument.  I've heard it from a dozen 
> 
> WHOA!  Back up.  I'm not trying to discourge psm from working at all.
> What I would like to see happen is for him to start working in a manner
> that doesn't hinder other developers.  All my fixes will eventually be
> made available as required.  But since psm was treating tip as his own
> branch, there's a level of instability that makes it impossible for me
> to work with.  You don't see kernel development taking place in that
> fashion, do you?  No... because groups of people simply can not work
> efficiently together in that fashion.

Well, I think this is a simple organization thing. Comparing the Linux
kernel with uClibc is probably not a good-working comparison because
of the different SCM choices.

When we were working with Linus being the "chief" of all and people
having some patches around, I tried to _not_ use the patches but to
stay with Linus's version, even if I needed to work around something
or wait for it being accepted "upstream."  With BitKeeper, I basically
did the same, but was more up-to-date wrt. Linus.  That's just because
I didn't want to care about patching (and fiddling with BK due to
license problems. For a good time, I wasn't allowed to use BK due to
the "don't work on a competing SCN.")

These days, we have GIT--and I really like it. For the first time,
I've really started patching local trees and maintaining a good number
of them, because maintainence now is so _damn_ easy. For uClibc, I'd
accept (even suggest) something like that, too. Keep trunk open for
risky changes and do "release" hacking on branches. Maybe introduce a
freeze for some days before creating a new release branch (as the GCC
team does.)

I was hit by build failures, too. Even multiple times. That "forced"
me into writing a nice set of tools to automatically build it once an
hour and report build log differences (and a final "SUCCESS" or "NO
SUCCESS" state.)  That actually helped me several times when GCC trunk
broke...

Nonetheless, many thanks for uClibc up to now. Getting VAX support
done was comparably easy (even while ld.so and pthreads is still
missing, which I still need to do...)

MfG, JBG
-- 
Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20060402/30ec3225/attachment-0002.pgp