On Sunday 15 February 2009 08:02:54 Denys Vlasenko wrote: > On Saturday 14 February 2009 23:52, Rob Landley wrote: > > svn 24278: mips bugfix renaming a function from __NTH to __cmsg_nxthdr in > > bits/socket.h. Ok. No idea what this fixes, and "merge from trunk" > > isn't helpful, but it's small and localized and svn's horrible branch > > infrastructure > > Rob, do you really think that complaining about something will help?
I'm pretty sure ignoring it won't. The message you responded to was primarily devoted to reviewing the 0.9.30.1 patches in hope of stimulating a 0.9.30.1 release. Considering that no uClibc stable release has built against the current Linux kernel release since 2.6.28 shipped on December 24, and since then the Linux kernel has had 5 bugfix-only dot releases, it seemed like publicly reviewing the pending patches might help. The complaining about SVN was large triggered by the facts that A) I had to put a lot more effort and persistence into finding the patches to review than most people were likely to do, B) nobody _else_ on the list seemed to be looking at the subversion branch either, or I wouldn't have had to do a review pass to draw attention to 'em. I think the real issue here is that uClibc's currently has no release version that builds against current kernels, not SVN, but by all means let's talk about SVN instead. (I again note that I've been more irritable than usual recently due to the Great Cedar Pollen Apocalypse of 2009: http://www.news8austin.com/content/headlines/?ArID=229892&SecID=2 . I'm heading out of town for a couple weeks starting Tuesday. It hasn't changed my opinions, but it may have had an impact on how tactfully I'm currently capable of expressing them.) > Do you think anyone is deliberately insisting on using svn > no matter what? Mike objected to moving off of it when I brought it up back in 2006. I don't remember his reason. > If you are sure that svn is soooo horrible, and you are willing > to invest your time in installing an alternative, migrating > the current installation to it, writing up email announcements > and "HOWTO use new shiny version control system"'s, > do necessary testing and so on, by all means please do it > (in cooperation with admins at osuosl). I take it you missed the hg mirror of the busybox repository I set up on the old morris back in 2006? (~landley/hg on morris still has an ancient svn2hg script in it, there's a half-finished updated version at http://landley.net/code/svn2hg2.py that I was in the process of adding mirroring support to when I got interrupted by His Bruceness). I haven't pushed it since because A) what source control system you use for busybox is your concern and not mine (I still have a patchlist creation script that turns the entire repository into patches like I'd attached, an old version of which is still up at http://busybox.net/~landley/toys/bb-doupdate), B) Bernhard is on record as preferring git to mercurial and made vague noises about maybe converting it himself someday, so pushing hg at him didn't seem useful, C) first having a maintainer for uClibc was more important, then moving the server was more important, and now I think time based releases are more important, D) I've been busy with totally unrelated projects. > At least I definitely won't object to it. I could ask the qemu guys what they're using in their current migration from svn to git: http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00916.html Since the arrival of distributed version control systems, subversion has turned into a tool for corporate users to develop proprietary software with. Even Subversion's own developers acknowledge this: http://blog.red-bean.com/sussman/?p=79 > Again, I repeat the irony: Subversion was designed for open source geeks, > but the reality is that it’s become much more of a “home run”for corporate > development. Subversion is centralized. Subversion runs on Windows, both > client and server. Subversion has fine-grained access control. It has an > absolutely killer GUI (TortoiseSVN) that makes version control accessible > to people who barely know what it is. It integrates with all the GUI IDEs > like VS.NET and Eclipse. In short, it’s an absolute perfect fit for the > 80%, and it’s why Collabnet is doing so well in supporting this audience. With a follow-up post here: http://blog.red-bean.com/sussman/?p=90 > But repeatedly writing acidic comments of "svn suxxx" style > is unlikely to get you anywhere (except maybe it'll infuriate > svn fanboys, if they are present on the mailing list). I complain loudly and constantly about the inadequacies of whatever tools I'm currently working with, and often go off on a tangent fixing or replacing a tool instead of finishing what I'd meant to be working on. I've been doing this for years now. That's how I got into busybox development in the first place: http://osdir.com/ml/linux.busybox/2003-10/msg00064.html http://osdir.com/ml/2003-10/msg00005.html I complain about my own stuff too. Remember how I rewrote mount around 5 times because I wasn't happy with the results of my own work? At the end of my Jan 7 blog entry from this year I call some of my own code "stupid" because I'd thought of a better approach. I believe this is referred to as the "mad scientist" working style: http://www.girlgeniusonline.com/comic.php?date=20030625 (Quick summary: they're plummeting to the ground in a broken flying machine, and arguing over the design of the engine.) But you're assuming that I want to replace svn with a different source control system for maintaining a bugfix-only branch. This is not the case. In this particular context svn merely adds insult to injury. I think _any_ full blown source control system is the wrong approach to take for bugfix-only dot releases, and a better fit would be something more like quilt: http://www.suse.de/~agruen/quilt.pdf http://www.shakthimaan.com/downloads/glv/quilt-tutorial/quilt-doc.pdf But even that's probably overkill. The point of bugfix-only dot releases is that you're not doing development there. You have a small and simple set of patches, which you release early and release often and then they do _not_ form part of a long-lived branch. You intend to stop maintaining this version after the next major release from the development branch comes out. Using a full source control system for this is like installing an SQL database in your cell phone to hold the speed dial list. I don't _want_ to have to compose an SQL query to get the numbers back, I'd much rather just hit "5" to dial the 5th number on the list. So my objection to svn specifically in this context is secondary, my main objection is that over the past 3 months 21 bugfix patches have accumulated with no review from the list, no easy way to see what they are, and no dot release to flush 'em all out. (Presumably the next bugfix release would accumulate patches vs the previous one, so the list of pending fixes goes back to zero with each dot release. Hence "flush 'em all out".) "Scalability" is bad here: in this context, 21 pending patches is too many. We should probably be up to about 0.9.30.3 by now. From a UI perspective, svn doesn't help the public review process. Neither the web page nor the repository browser interface even hint that this branch _exists_, and once you do figure out you need to go to http://sources.busybox.net/index.py/branches/uClibc_0_9_30/ (based entirely on a knowledge of how svn works with no hint from uclibc.org where to find it), there's no way to get a list of patches since this branch forked. (How many patches are specific to this branch? What are they? At what commit number did this fork from the development branch anyway? I had to use my patchlist script to find this stuff out.) I think the patch directory approach you take for busybox, ala http://busybox.net/downloads/fixes-1.13.2/ is just about perfect. (My only quibble is that there are now enough of those directories in busybox.net/downloads that they should probably be moved into their own subdirectory at some point, ala "downloads/fixes/1.13.2".) That approach is not designed to scale to large number of patches because having a large number of bugfix-only patches without having cut a release yet is a bad thing in this context. Instead, this approach is designed to make it easy to see the small number of simple fixes you have pending, so you can tell at a glance what's changed. I like it. Bernhard doesn't need my help to implement such a scheme, he'd just need to stop assuming that "taking a patch" is the same as "checking it into svn". But I really haven't got the reserves of tact to bring up that sort of issue just now, and haven't for a month. (Cedar pollen. Imagine having a headache, runny nose, coughing, and dry eyes, for four weeks. Now try to be tactful.) Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
