Now I'm curious...

[Rob Landley]

On Tuesday 04 September 2007 8:21:13 am Denys Vlasenko wrote:
> On Tuesday 04 September 2007 08:44, Rob Landley wrote:
> > 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*
>
> I saw Linus' video.
>
> Distributed SCM is nice for development, but at the end of a day,
> people want to go to some "official" place and download a "latest stable"
> version.

Yes.

> It's doesn't matter that developers use git or mercurial, 
> the code has to eventually end up at http://www.uclibc.org/downloads/.

Yes and no.  When the maintainer of XFree86 threw out Keith Packard, he went 
off and started his own fork and the entire world followed.  Glibc 2.0 and 
egcs were (more or less) such forks, prompted by stagnation.  Back before 
Linus took up source control and was dropping the majority of patches on the 
floor (even the ones from maintainers), Alan Cox retired from Linux 
development for a year (went off and got an MBA) because people were starting 
to consider his tree the official one, and push him to become the new point 
man, and he didn't want the job.  (More distros shipped stuff based on 
the -ac tree back in 2002 than on Linus's tree.)

> In the long run, successful long-term project must be usable by _users_,
> and users want to be able to figure out where "latest code" is,
> they don't want to search through forest of git/mercurial trees.

I think the ethereal userbase managed to find wireshark.

http://www.linux.com/articles/54968

> Of course, if there is no agreement between maintainers
> and development slows down, sometimes it is naturally resolved by forking.

*shrug*

I'm not promoting any specific course of action, but a uClibc tree has come to 
my attention with about 30 times as many patches since 0.9.29 as mainline, 
and it's maintained by a guy who's answered over half the obscure technical 
questions I get stumped on about arm soft float and such (often answered by 
providing me patches).  This developer will not return to this list, and has 
no interest in inheriting the existing tree (which is in an obsolete source 
control format anyway, and the new tree is mercurial which is my first choice 
these days anyway).

> > It will be decided to do a release by whom?
>
> By whoever is doing most of maintainer's work.

Anyone can put out a release.  I put out a release of my tcc fork:
http://landley.net/code/tinycc/downloads/

And I plan another one soon.  That is rampantly unofficial, I have no access 
to tinycc.org and wouldn't commit to a CVS tree unless well-paid to do so.  
But there are people using my fork.

> > 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.
>
> Do you propose someone to take these positions?

I'm pointing out the nature of the problem.  PSM is currently _doing_ the 
first, he's just not doing it publicly, nor in the context of this mailing 
list or the svn tree on uClibc.org.

The second job doesn't have to be done by the same guy.  Stable releases 
involve snapshotting the tree and applying bugfix patches only.  There's less 
of a judgement call involved in that, especially if new stable releases come 
out often enough that the decision to leave a feature out until the next 
release isn't particularly painful.  I could theoretically take the second 
job, but it's useless without the first.

> > 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
>
> http://kernel.org/ still exists, because people want to have "official"
> tree.

Sure.  But if the "official" tree stops being the best tree to use, people 
will notice after a while.

Between 0.9.28 and 0.9.28.1, uClibc went 16 months without a release.  And 
when there _was_ a release, it was bugfixes for the previous version.  The 
unstable branch had numerous new features that a decent chunk of its userbase 
couldn't live without, and they got used to using random svn snapshots in 
production.  The maintainers actually recommended this.  In fact, with the 
adjacent project buildroot, that was the _only_ option.

I think this has greatly eroded the tendency to think of the uClibc.org 
release tarballs as the point of the wedge.  So what does that leave, svn?  
So in current svn, which tree is taking point right now?  Is it trunk/uClibc 
or is it branches/uClibc-nptl?  Which one is slated to become 0.9.30?  I 
honestly don't know.

It's hard to have any kind of attachment to the existing tree under those sort 
of conditions.

> > 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 have nothing against people using mercurial/git, it's just not
> very relevant to the question "how to energize uclibc development?"

Not to me it isn't.  I converted the uClibc tree to mercurial just to follow 
development (http://landley.net/hg/mercurial), and since my conversion script 
broke (tailor is buggy) I haven't really been following the tree here at all, 
other than the occasional peek at the web interface to it to see if some 
problem or other is still relevant.

> "Let's all switch to mercurial/git" doesn't solve it.

Not by itself, no.  It's just one factor I take into consideration when 
deciding which upstream to follow.

I am a user of uClibc.  I contribute the occasional patch and bug report, but 
I'm busy with my own projects, and mostly I'm looking for an upstream source 
to consume.

What I'm doing here is examining my options.  I'm not making any 
recommendations to anyone else, and certainly not trying to make trouble, but 
I am sharing my reasoning in the spirit of being open and fair to the other 
uClibc users.

I don't currently know whether or not following PSM's tree is a better choice 
than following the one here, but I do know that it's an order of magnitude 
more active, and over the past year I've actually gotten slightly more of my 
technical questions answered offline by Peter than on this list.  (That's 
important to me: when I have a question I'm personally comfortable talking to 
Peter about it.)

In the current tree, I don't know which branch to follow and neither has shown 
significant activity in a month.  Mike and sjhill are essentially MIA (and 
although I respect their technical skills I've never personally seen eye to 
eye with either one on development philosophy anyway.  I'm not too interested 
in talking directly to them because it just devolves into an argument on the 
things we disagree about.)  Despite me asking here more than once, there is 
no activity towards a 0.9.29.1, which is my short-term interest.

I have no major incentive to change how uClibc development works.  I knew Erik 
and was happy to help him out, but he's moved on.

Perhaps the slowdown here is a temporary lull, but meanwhile I'm off playing 
with other stuff...

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