Now I'm curious...

Denys Vlasenko vda.linux at googlemail.com
Wed Sep 5 10:18:32 UTC 2007


Hi Rob, folks,

On Wednesday 05 September 2007 00:38, 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.)

Yes Rob, basically you explain that when maintainership is bad,
eventually someone else forks or takes over development.

I am not arguing against it, I am merely saying that majority of
end-users wants to download a release from website, not fetch
"svn head" of "git tree".

It can be something else than http://www.uclibc.org/downloads/,
but it has to be http://www.SOMETHING/downloads/.

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

As I see it, there are basically these possible courses of action:

* Change nothing; or

* Ask current uclibc maintainers and Peter whether they are interested
  in applying his work to svn, having him continue to work on svn head and
  him putting out releases, at which point further stabilization
  of release branch is done by current uclibc maintainers
  and/or Rob Landley; or

* Ask Peter to start putting out his own releases _somewhere else_ than
  http://www.uclibc.org/, and see how good it will be in the long run.

Can you give me Peter's email address?
--
vda



More information about the uClibc mailing list