Retiring from uClibc development

[Rob Landley]

On Saturday 01 April 2006 9:41 pm, Manuel Novoa III wrote:
> > > > 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.
> > >
> > > Thought I had been pretty clear.  My main "objection" was that psm was
> > > treating trunk as his own branch.
> >
> > Objecting that he's checking in code that's not properly tested yet is a
> > different objection than saying other out-of-tree code is delayed by
> > commercial concerns.  I was under the impression he had been testing
> > against gentoo embedded.  (I was also under the impression that's what
> > vapier was posting nightly tests of.)
>
> Delayed commercial concerns?  If anything, users are more affected.
> If I were actually able to use the svn trunk, some of my fixes would
> likely already be in.  But I can't and am forced to maintain my own
> tree, thereby severely limiting or even eliminating opportunities to
> participate in development of tip.  Hard to justify working on a tree
> I can't even currently use.
>
> Similarly, it has thrown roadblocks in sjhill's path towards getting
> NPTL support into uClibc.  If you want to call that a "commercial
> concern", fine.  But realize that it has also pushed back the release
> of this code to everyone and hence everyone suffers.

Apparently I misunderstood the situation, then.  I regularly couldn't get the 
tree to work for me between 0.9.27 and 0.9.28 (I have horrible luck with 
random svn snapshots, always have), so I didn't realize this was considered 
new.

> > > Instead of working in his own branch
> > > on several projects that touch tons of files in the libraries and then
> > > merging those in several logical atomic commits when reasonably
> > > complete and stable, he's been churning svn with lots of piecemeal
> > > commits which get intermixed with bug fixes, other updates, etc.
> >
> > You mean as opposed to
> > http://news.com.com/Open-source+divorce+for+Apples+Safari/2100-1032_3-570
> >3819.html http://www.kdedevelopers.org/node/1001
> >
> > He's forking the tree by checking stuff in promptly?
>
> No one is talking about forking.  At some point I see things commonly
> merged.  That's why I have said that I'm on my own branch and I look
> at current tip as psm's.

Ok.

> > > In sjhill's case, trying to keep in sync with trunc has measureably
> > > added to his development time for adding NPTL support to uClibc.  In my
> > > case, needing a certain level of stability and auditability in the
> > > tree, which is how Erik and I have always worked on uClibc,  I've been
> > > forced to work in my own branch exclusively and to consider current svn
> > > trunk to be psm's branch.  From what Erik has told me, he's been using
> > > .28 + patches for his own work as well...
> >
> > As have I, but I did that for 0.9.27+patches and 0.9.26+patches too.
>
> The difference being that you don't do uClibc development.

I've done a little, but nothing worth merging yet.  My concerns were generally 
some package that didn't build, and a quick hack to not actually fix that, 
but make it go away for now.  The biggest roadblock (other than time) is that 
until recently I didn't have test platforms for anything but x86, and I've 
never gotten buildroot to do anything useful.  (Tried again last month.  It 
built an arm image that qemu won't boot, then trying to build a ppc one 
broke.  Wheee.)

> > > although I know he tried building current tip last
> > > weekend.  How can this state of affairs be good for developers or
> > > users?
> >
> > Sounds like the reasons Linux development went to git.
>
> Amazing... ANOTHER example of people working in their own trees until
> things are ready to merge.  Imagine that...

I'm not saying it's bad.  Quite the opposite.  I'm just saying that svn isn't 
really set up to deal with that.  Hence the talk about other tools.

> > I'm told there's a tool called svk that does something similar to svn,
> > but I can't use it on busybox because some people rectally inserted the
> > udhcp into busybox and that confuses svk.  I'm still working on removing
> > it, not ready to check in yet.
> >
> > > As far as a release, I'd imagine there will be one after sjhill
> > > releases the rest of the NPTL changes.  You'd have to ask him or Erik. 
> > > Cutting a release may even be part of the contract.
> >
> > Did Erik sign it?
>
> Ask him.
>
> > > As an aside, I typically
> > > personally don't advocate cutting a release _unless_ there's a contract
> > > involved.
> >
> > So uClibc should never have had any releases before 0.9.26 or so?
>
> More uClibc releases have occurred _because_ of contract work than not.
> I should know, having been involved in virtually all of them.

Ok.

> > > I look at releases as an incentive for companies using uClibc
> > > commercially to help fund development.
> >
> > Because development never happens unless it's funded?
>
> You put a lot of importance on releases.

Yes.  They're what I use, and what I base what little development I do off of.  
(Another reason I haven't looked at checking anything in: by the time I get 
around to poking at anything, the base is too out of date to be relevant.)  I 
currently care because there are two bugs I know of that busybox triggers in 
current 0.9.28 (mdev -s and tar xvjCf), at least one of which is fixed in 
current svn (the one mdev -s hits).

I've recently pondered redoing the regex stuff in uClibc, but somebody 
mentioned some other regex library getting released recently so it went 
farther down on the todo list.  I also pondered poking at the uClibc option 
parsing stuff, but I still need to see if I can work around it by cleaning up 
the busybox option parsing to not trigger the bug in the first place.

> So do a lot of companies 
> using uClibc commercially that have never contributed to its
> development.  Holding off releases can provide an incentive for some
> of those companies to fund development, which in my opionis is good
> for users in the long run.

First I'd heard of any of this.  I just thought the project kept stalling 
because people working on it were busy with other things.  I had no idea it 
was like a telethon: donate and the program resumes.  (Maybe this is 
something that went by on IRC while I wasn't on...)

I'm obviously not speaking for my employer here but just FYI Timesys is still 
maintaining the old uClibc wrapper in-house, updated to gcc 4.x.  They don't 
build a separate compiler for uClibc, they put more work into the wrapper 
instead.  (As far as I can tell, they've never managed to get buildroot to do 
anything interesting either.  And their customers tend to want RPMs anyway 
because that's what the Linux Standard Base says and they want to be 
standards compliant, so all they _would_ be using buildroot for is building a 
toolchain, not a system.)

They're not hoarding the source code to that, not only do their customers get 
copies (under the GPL of course) but the updated wrapper is even available as 
a free download on some web page or other (if you track it down and dig it 
out of the appropriate tarball, anyway).  But why would they post it to this 
list if uClibc explicitly abandoned that approach, and is no longer 
interested?  Line of public development ends, you continue it in house, isn't 
open source great that it lets you do that?

The general mindset of just about all the companies I've encountered is that 
if the project's development is too slow, they extend it in house, ship 
source to their customers if that's what license compliance takes, possibly 
even make this sort of dump if somebody asks:
http://www.uclibc.org/lists/uclibc/2006-January/014963.html

A year and a half ago, I had a brief contract at a company that was using an 
open source project that had stalled _five_years_ earlier.  They just 
maintained their own in-house branch.  Yes it was sad that the original 
project had stalled, but wasn't it nice that it was open source so they could 
maintain it themselves after that happened?  This is something they used on 
their servers rather than shipping to customers, so putting it out for the 
world never even came up.

The slower the project is issuing new releases, the less downside there is to 
not merging.  Slowing down releases in hopes of shaking out contributions of 
code or money from companies strikes me as somewhat counterproductive.  
Especially in the absence of prominent efforts to get the word out about how 
to make it go faster.

> And no... there are very few contracts I'd be 
> willing (or even have time) to take, so this isn't me being selfish.

Didn't say it was.

I care about what's best for the project.  I didn't say I knew what that was, 
and I may not be in the world's best position to affect the outcome either.  
That's why I mostly just lurk here.

I've expressed my opinion, it has been duly noted, and I'll shut up now.  Off 
to spend time on other things...

> Manuel

Rob
-- 
Never bet against the cheap plastic solution.