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 _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
