Retiring from uClibc development

Manuel Novoa III mjn3 at codepoet.org
Sun Apr 2 02:41:23 UTC 2006


Rob,

On Sat, Apr 01, 2006 at 07:20:06PM -0500, Rob Landley wrote:
> 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.

Which _public_ contributions are you talking about?  If someone is paying
for the work to be done, it isn't public until they actually release
something using it.  And how are anyone's contributions restricted by
following the same mode of development that Erik and I and sjhill are
using and in fact have been using since Erik forked uClibc from uC-libc?

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

You've got it backwards.  While both Erik and I have put in a lot of
personal time on uClibc, _most_ of uClibc development has been funded
by contracts.

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

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

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.

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

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

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

Manuel




More information about the uClibc mailing list