To start off with, here’s a function from my ~/.bashrc file. Gmail has an unfortunate insistence on forcing line breaks. This can be an issue when working with the Debian BTS as you need to interact with the control server through one line commands sent via email. The place where this is always the most painful for me has been in marking bugs as forwarded upstream. So I figured I’d make my life easier by just doing it on the command line:

function bts-forward () {
    if [[ "$1" == ${1//[^0-9]/} && "$2" == http* ]]; then
        echo "forwarded $1 $2" | \
        sendmail -f"$DEBEMAIL" control@bugs.debian.org;
    else
        echo "Usage: bts-forward DEBIAN_BUG UPSTREAM_URL"
    fi
    }

I’ve been following the discussion around the potential switch from Banshee back to Rhythmbox for Precise, and I really don’t have all that much to add. Though I did come across an interesting post from an upstream Tomboy developer that deserves some wider attention. He argues that “upstreams would be more than happy to do a lot of stuff for Ubuntu if only Ubuntu actually let them know what they wanted in some sort of predictable fashion.”

Ubuntu either doesn’t know how important they’ve become, or they don’t care. Developers in upstream apps know that getting exposure in Ubuntu means an incredible influx of new users, which in turn leads to new bug reporters, which finally means new contributors. It’s well known that each of these groups is an order of magnitude smaller than the last, so making sure the user group is as big as possible is vital for an application. And because upstream knows this, they are willing to bend over backwards to accommodate Ubuntu’s wishes.

He also tells a story about Tomboy nearly being dropped last cycle due to depending on a number of libraries that the desktop team wanted to drop form the CD images. He goes on to suggest that formalizing the procedure around these sorts of things would reduce a lot of confusion and let upstreams know where they stand.

This seems entirely reasonable to me. The Banshee issue aside, it would be great if there was a formal announcement at some set point in the cycle where the targeted development goals for the platform are laid out in one place. If you follow closely this information is already announced, but it is in a trickle of different messages to the devel and desktop lists. The  idea would be to compile this information into one clear widely-publicized announcement. It would be early enough in the cycle that upstreams, derivatives, and other stake holders would have time to react. It would also make clear that any discussion before that point is just that, discussion not  decisions. The existing Feature Definition Freeze would probably make for a nice fit.

I also figured I should take a look at ubuntu-devel:

That graph raises the question what happened at the end of 2006. Of course, that was when ubuntu-devel-discuss was started:

I’m not sure what this all means, but I do find it interesting in the context of some recent discussion on the direction of the Ubuntu community.

—-

You can find the python code I used in a GitHub gist. It takes an mbox file and produces a histogram using matplotlib. It is shamelessly based off of code by Takafumi Arakaki that was designed to plot a histogram of the commit frequency of a Mercurial or Git repository by reading newline separated unix time via STDIN. I just rewrote the read_dates() function. If someone has a simpler way of doing the date conversion, I’d love to see it. What I did was a bit convoluted.

An election for a recently opened spot on the DMB has just begun. While all the names of those nominated are familiar to me, I still need some more information to make a decision. All of the candidates are eminently qualified. Unfortunately, the call for votes didn’t include any statements of intent from the candidates. Votes will be accepted through 2011-09-06 12:00 (presumably UTC). So perhaps we’ll hear from the candidates themselves. Until then, to save others a little bit of Googling, here are their Launchpad profiles and Ubuntu wiki pages:

• Charlie Smotherman (porthose) - Launchpad – Wiki
• Micah Gersten (micahg) - Launchpad - Wiki
• Stefano Rivera (tumbleweed) - Launchpad - Wiki
• Dave Walker (Daviey) - Launchpad - Wiki

So without further adieu, I am announcing that I will be maintaining a public Google Calendar for the Ubuntu release schedule.

• HTML - http://goo.gl/q4yZV
• ICAL - http://goo.gl/TUzUd

• 17k Questions
• 31k Answers
• 19k User
• 21k Visits/Day
• 81% of questions have accepted answers

• How to restrict / limit the number of RDP sessions?
• How do I configure a fingerprint scanner?
• How to set up a Serial-to-Ethernet Converter With a Virtual Serial Port?
• How do I share files with a Mac?
• Where are debug symbols for backported packages?
• Anyone using KVM with Spice protocol on Ubuntu?
• Check if pendrive is persistent?

The old key was:

pub 1024D/6286FB6D 2007-11-03
Key fingerprint = 62EE D4F4 6D46 BE9E FF02 220A 2F89 3E7C 6286 FB6D

And the new key is:

pub 4096R/D53FDCB1 2010-09-24
Key fingerprint = 6EB2 23D7 D71E 67A5 3C93 A7DA 3B56 E2BB D53F DCB1

To fetch my new key from a public key server, you can simply do:

gpg --keyserver pgp.mit.edu --recv-key D53FDCB1

If you already know my old key, you can now verify that the new key is signed by the old one:

gpg --check-sigs D53FDCB1

If you don’t already know my old key, or you just want to be double extra paranoid, you can check the fingerprint against the one above:

gpg --fingerprint D53FDCB1

If you are satisfied that you’ve got the right key, and the UIDs match what you expect, I’d appreciate it if you would sign my key:

gpg --sign-key D53FDCB1

Lastly, if you could upload these signatures, i would appreciate it. You can just upload the signatures to a public keyserver directly:

gpg --keyserver pgp.mit.edu --send-key D53FDCB1

Thanks!

Doctors Without Borders/Médecins Sans Frontières (MSF) is an independent international medical humanitarian organization. If you can spare even a few dollars to help in the emergency efforts under way in Haiti, I strongly recommend giving what you can to MSF.

I don’t really have much to pontificate on so this will be quick, but there are a couple things to share.

My roommate ending up being Daniel Fore, designer of the elementary icon set that the Humanity icons are based on. So I was able to help get them up on a PPA.

You can grab packages based on the latests Bazaar trunk for Karmic.

I mostly focused on attending sessions on bug management and distributed development today. I saved copies of the gobby notes for each session I attended:  http://people.ubuntu.com/~andrewsomething/uds-l/notes/

The plenary session demoing Quickly made me excited to dive back into python. The videos aren’t up yet, but there are previous screen-casts showing it off.

One of the things that I’ve always loved about bzr is that it is a powerful yet intuitive solution for version control. Now Bazaar Explorer, a wonderful cross-platform Qt-based GUI front-end to the Bazaar VCS, is making it even easier. Whether you’re just getting started with DVCS or you just prefer a graphical environment, you should really check it out. (You can take a tour here.)

There’s been a Windows installer for Bazaar Explorer for awhile, and of course the source code is over there on Launchpad. Even though Bazaar’s plugin system makes it simple to install it on Linux from source, it just doesn’t feel like it’s keeping with the theme of making things easy. So I went and packaged it for Ubuntu!

You can now grab it from the Bazaar Explorer PPA. It should be entering Debian Unstable and Ubuntu Lucid in the near future, but we want to give you PPA users the chance to kick the tires first. Just add ppa:bzr-explorer-dev/ppa to your system’s Software Sources.

There are packages for Karmic, Jaunty, Intrepid, and Hardy in the PPA, but please note that as bzr-explorer depends on bzr (>= 1.14) and qbzr (>= 0.11), users of Ubuntu releases before Karmic will also need to add the PPA for Bazaar Developers.  Also be aware that Hardy users might have some issues as parts of Explorer (e.g. the Preferences dialog) depend on Qt/PyQt 4.4.  (See: Bug #429549). That said, every thing should be working smoothly in Karmic.