Re: Two years of Python

Andrew writes about Python, Perl and Ruby:

Ruby has some nice things (like Perlish regular expression handling), but it brings back all that punctuation noise again.

He gives an example of punctuation noise in Perl:

I go back to Perl and my eyes bleed after trying to dereference a reference to a scalar, or something like that. It’s just ugly in Perl.

I don’t think that’s fair to compare Perl’s ponctuation noise with Ruby. Ruby has a feature that could qualify as punctuation noise, but it’s really a feature: variables are prefixed with their scope. For example, class variables start with @@ (@@var), instance variables start with @ (@var), global variables start with $ ($var), and constants are in CAPS.

I don’t know if Ruby “invented” that, or if it comes from another language (it’s probably the case: Ruby takes a lot of good ideas everywhere).

Also, Andrew, joining elements of an array in ruby is written myarray.join(” “), and Ruby has =~. So you should definitely give Ruby a try ;) No, seriously, Ruby is a really interesting language. It’s really a shame that it’s still so japanese-centric (most development decisions are taken on a japanese mailing list !!), since it’s not really help a wide adoption.

Where is the NM bottleneck?

The current status of the NM process, with 1 NM awaiting FD approval, 7 awaiting DAM approval, and 30 waiting for their accounts to be created, leads people to thinking that the big bottleneck is the account creation stage. However, when you look at what happened since december 2005, it’s not that simple.

NM queues status

See the graph linked above, which shows where people are waiting. While it seems that the FD stage hasn’t been blocking people for nearly a year, it’s the DAM stage which has been the biggest blocker. Indeed, on average, 8.3 NMs have been blocked by FD, 16.2 by DAM, and 9.0 by account creation.

I understand that processing NM reports in batch mode makes it more efficient. However, I’m wondering if processing them 20 per 20, is really that more efficient than processing them 5 per 5, which would justify such long queues. The NEW queue, which used to be a problem, is now being processed on a very regular basis, and hasn’t grown widely recently, except after Debconf when the ftpmaster processing NEW was on VAC. Couldn’t we have the same thing for DAM, account creations, and while we are at it, removals from unstable? Having clearly defined human-crontab-jobs would certainly make working on Debian less frustrating.

SC07, MIT Fab labs, and empowering people

This morning’s SuperComputing’07 keynote was a talk by Neil Gershenfeld, director of the Center for Bits and Atoms at the MIT. He mentioned the MIT Fab Labs, a project to bring “Personal Fabrication” to people around the around.

At our own level, that’s something I find very exciting with Free Software: it empowers people to do things with their computers that they couldn’t do if they were using proprietary software, simply because proprietary software is built to fit most people’s needs, not very specific goals some people could have. (and this is similar to the Long Tail stuff, in some ways)

Also, if you are at SC07 and reading this, feel free to ping me! I haven’t seen a lot of Debian/Ubuntuers here, even if the Free/Proprietary software ratio is very high.

Some numbers about Debian’s history

There’s an interesting article on about Gentoo: Who made Gentoo Linux, and when? A commit analysis

I was wondering how Debian compared, so I made some stats using the debian-devel-changes archives.

First, the number of source uploads per quarter:

It’s interesting to note that, while the number of packages in Debian increased a lot, the number of uploads basically stayed the same since 2001.

Then, I wondered about the number of active developers in Debian. So I counted:

  • The number of different email addresses in Changed-by
  • The number of different keys used to sign uploads

  • The number of active devs has been slightly decreasing over the past years.
  • The difference between the number of different changed-bys and the number of different keys should be the number of sponsorees, if I understand everything correctly. It is increasing a lot, which probably means that we have a bandwidth problem at integrating new contributors. Hopefully the DM GR will help at reducing that gap.

I can provide the raw data on demand, if someone else want to work on this. There’s probably a lot of other interesting things to do!