Review of pending 0.9.30.1 patches, with tarball.

[Rob Landley]

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