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