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