Now I'm curious...

Denys Vlasenko vda.linux at googlemail.com
Tue Sep 4 13:21:13 UTC 2007


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

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.

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

> It will be decided to do a release by whom?

By whoever is doing most of maintainer's work.

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

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

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

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



More information about the uClibc mailing list