Now I'm curious...

Rob Landley rob at landley.net
Tue Sep 4 07:44:24 UTC 2007


On Monday 03 September 2007 9:13:50 am Denys Vlasenko wrote:
> On Sunday 02 September 2007 09:14, Rob Landley wrote:
> > The official uClibc tree has seen 35 patches since the 0.9.29 release. 
> > That tree hasn't been touched in a month.  The uClibc-nptl branch
> > (scheduled to become 0.9.30) was last touched 5 weeks ago, and before
> > that 4 months ago. The last time the uClibc maintainer posted to this
> > list was in May.  It is now September.
> >
> > The uClibc project is, for all intents and purposes, on hiatus at the
> > moment.
> >
> > Meanwhile, Peter S. Mazinger says his uClibc tree has 1194 commits
> > relative to 0.9.29.  (That's one thousand, one hundred, and ninety-four.)
> >  I just had a longish conversation with him on #gentoo-embedded on
> > freenode, during which he showed me how to patch uClibc/Rules.mak to get
> > armv4l soft-float working.
> >
> > Peter unsubscribed from this list almost exactly one year ago, due to
> > disagreements with Manuel Nova and Steven Hill:
> > http://www.uclibc.org/lists/uclibc/2006-March/015014.html
> >
> > Manuel's objection was that Peter was making too many changes and
> > checking them into the development branch, which was making it hard for
> > other developers to keep up:
> > http://www.uclibc.org/lists/uclibc/2006-March/015018.html
> >
> > Steven's objection was that he was getting paid to do large uClibc
> > changes out-of-tree, none of which would be merged until the end of the
> > contract, and that changes to the public tree in the meantime made more
> > work for him keeping his out-of-tree stuff in sync, and therefore Steven
> > wanted Peter to stop interfering with Steven's contract by doing rapid
> > unrelated development:
> > http://www.uclibc.org/lists/uclibc/2006-March/015048.html
> > http://www.uclibc.org/lists/uclibc/2006-March/015049.html
> >
> > Peter's last post (asking how to unsubscribe) was August 25, 2006. 
> > Steven and Manuel got what then wanted.  Does it seem to anyone else here
> > that a year later, the result is that uClibc development has effectively
> > ground to a halt?
> >
> > I'm poking Peter to put out a release.  I'll let you know if he does. 
> > (I'd happily send _him_ a cake, but he appears to be in Europe...)
>
> uclibc development indeed is a bit too quiet for my tastes, yes.
>
> After reading those mails it seems to that Manuel and Steven simply didn't
> trust Peter's code enough to allow him to commit stuff to head and feel
> more-or-less comfortable with taking head at some pelease point
> and use it for production systems.
>
> They basically say thet they were maintaining head in a much more
> stable form before that.
>
> The truth is, stability and development are mutually exclusive, if you want
> more stability, you inevitably lose some development speed.
> And this is exactly what happened.

It's a compromise, and the way to make it work is timed releases rather than 
feature-based ones.  See the bottom link on this page for a nice google video 
about that:
http://kernel.org/doc/video.html

I'm quite fond of the "x.y.z release" every six months, with bugfix-only 
x.y.z.1 and x.y.z.2 coming in between.  The bugfix releases can be put out by 
somebody other than the development guys.  That's what the kernel's doing 
now, that's what I did during my tenure on Busybox, etc.  Worked just fine, I 
thought. :)

> How the current situation can change:
>
> We can decide to allow more unstable uclibc svn head,

Er, "deciding to allow" means nothing if nobody does the work.  My objection 
is that people who were chased away from the current uClibc tree have since 
been doing more work than the people who did the chasing.  That doesn't seem 
efficient, somehow.

I don't care which tree is "official".  That means very little to me.  I don't 
poke at svn much anymore now that I've moved on to distributed source 
control, and although it's _polite_ to post my fixes back here, if they don't 
get integrated oh well.  My uClibc tree supports miniconfig.  uClibc 0.9.29 
does not.  *shrug*

> with the agreement 
> that when it will be decided to do a release, we will have x.x.0 unstable
> and people will work on fixing on the regressions for x.x.1, x.x.2,
> _especially_ on the regressions caused by *their* changes.

It will be decided to do a release by whom?

There are two editorial jobs involved in maintaining a project:

1) Deciding what to merge (and how), which often means saying "no" to the 
majority of submissions for the purposes of fighting off Sturgeon's Law.  
Book and magazine publishers do exactly the same thing with the "slush pile", 
and movie producers do this with screenplays: this is nothing new.

2) Putting out stable releases.  I've already mentioned I like time-based 
ones, and the video does a good job of explaining the benefits in detail.

An interesting point is that the person putting out stable releases and the 
person controlling the development tree don't HAVE to be the same person.  
Especially once a stable release _has_ been issued, maintaining bugfix-only 
stable releases is often best done by somebody OTHER than the maintainer of 
the development branch.

I got burned badly enough over in busybox-land that I have no interest in 
being the development maintainer of any remotely related project, but I'm 
vaguely interested in putting out bugfix-only releases in the stable branch 
of a product I use and have to patch to collect fixes for anyway.

> Between releases, people who need stable uclibc will use last stable
> release, and add bugfixes for that release to it's own stable branch.
>
> This doesn't mean that any developer with write access can dump
> any kind of untested half-baked code to head. It is expected that it
> compiles and has at least some sort of testing done, and it is expected
> that developer will be responsive for bugs discovered in it and reported
> on mailing lists.
>
> IOW: we can try to buy a bit of development speed by sacrificing on
> head stability. We can try to trust people with write access a bit more
> that they will be good at fixing their own breakage.

If you use a modern distributed source control system, there's no concept 
of "commit access".  You can watch Linus Torvalds explain this on video, and 
hear him call CVS and SVN all sorts of nasty names. :)

http://video.google.com/videoplay?docid=-2199332044603874737

Personally, I'm quite fond of Mercurial, as you can see 
at "http://landley.net/hg".

Also, I just heard back from Peter whose tree is indeed in Mercurial.  
(Although not online at a permanent location, just when he leaves his machine 
on running "hg serve", and the URL he emailed me last night is down at the 
moment.  Possibly on a dynamic IP.  I've asked him if I can mirror it on my 
website...)

> I think it is worth trying, but I am a very small player in uclibc field.

I'm a small player in the uClibc field, but mostly because I have chosen to be 
so.  This can change, although my spare time's in short supply these days...

> --
> vda



-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.



More information about the uClibc mailing list