Retiring from uClibc development

[Rob Landley]

On Saturday 01 April 2006 2:49 pm, Manuel Novoa III wrote:
> Rob,
>
> On Sat, Apr 01, 2006 at 01:01:05PM -0500, Rob Landley wrote:
> > On Monday 27 March 2006 7:12 pm, Manuel Novoa III wrote:
> > > Also realize that I haven't stopped my own development for uClibc.  It
> > > just takes place in my own tree.  When we release something linked with
> > > it, the patches will be made available and integrated.  But I can't
> > > ethicly (at least in my code of ethics) justify handing out bug fixes
> > > to my employer's competitors until necessary.
> >
> > Disturbing trend.
>
> That's ambiguous.... What precisely do you find disturbing?

Multiple prominent uClibc developers explicitly subordinating their public 
contributions to commercial concerns, to the point where they'd like to 
restrict other people's contributions to the public tree because of it.

I guess it's fallout from the project being advanced enough that it's now 
possible to make money doing it...

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

> 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-5703819.html 
http://www.kdedevelopers.org/node/1001

He's forking the tree by checking stuff in promptly?

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

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

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?

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

> I look at releases as an incentive for companies using uClibc 
> commercially to help fund development.

Because development never happens unless it's funded?

> Manuel

Rob
-- 
Never bet against the cheap plastic solution.