Jacob Peddicord

Programming, Projects, and Packaging Problems

It's time for some long-overdue updates on some software projects of mine. I'm posting this not only to show some things I've got planned, but also to motivate myself to do something about them. When something is written down and shared, I'm much more likely to get things done, I've found. So this is going to be a bit of a braindump, but read on if you're interested.

Project Hosting

First, I want to get this out of the way. I can't stand Launchpad. I'm sure it works great for many, many people (I hear this distribution called Ubuntu uses it) but there are far too many small things that prevent me from developing effectively with it. Project pages are a bit of a mess, code hosting is definitely a bit more convoluted that it should be, and releasing software becomes a burden rather than something exciting. Additionally, it only supports Bazaar, which is a decent DVCS, but I'm more of a Git fan. (Launchpad developers, please don't take this as blatant criticism, but see it as a challenge against the other offerings out there!)

So, I'm migrating my projects to GitHub. There are quite a few things that I really like about GitHub. For one, it's really easy to release software versions. Just tag a revision. Done. It will show up in the Downloads section, can have reports attached to it, and is all around easy to use. One thing I will miss from Launchpad, however, is bug reporting. Launchpad has the most complete bug and issue tracking around, though GitHub is certainly making some strides in that area.

Packaging

I'm not going to lie: I despise Debian packaging. It's just not my thing. There are too many variables to keep track of, too many subtleties, and too much politics. I'm sure some people love to dissect and create packages to distrubute the software we use, and I salute you.

It's getting to the point where I dread releasing a bugfix update, because I have to package it. And then it needs to go through a review process to make it into various software archives. That's fine; you want your processes to keep your archives of high quality. But it just takes too much time. When I was working on jobs-admin and jobservice last summer, I had to set aside a day practically every week to fix packaging quirks and go through archive processes. It's mundane, and I'd much rather be working on software itself than the logistics of distribution.

Not to say that I don't respect a typical software release process. I just dislike packaging specifically. If anyone has some words of wisdom on this, I'd love to hear it.

Projects

Enough of that, here are status reports on the software projects I've been working on:

jobservice and jobs-admin

These two have been suffering the worst from the packaging problem. Maverick, Natty, and soon Oneiric will all have jobservice/jobs-admin 0.8.0. Unfortunately, there was an API change in Natty's Upstart + DBus that causes Upstart jobs to not work in either of those. I've got the fix as 0.8.1 on GitHub, but have been unable to find an ample amount of time to get the packaging done.

And I feel really bad about this. That's why I'm writing this post; to convince myself to do something about it. jobservice and jobs-admin have had some sizable changes for a version 0.9 (to-be 1.0), but there are some things I still want to get done:

• Recovery mode functionality (it doesn't work 100% at the moment)
• Cleaned up settings interface
• Complete Upstart support: it works in 0.8.1, but doesn't use override files
• systemd support -- I want to make this largely distro-independent
• GitHub migration
• An actual support/project website
• Independent packaging repository (maybe)
• More complete SLS files for newer system services

Once I'm at a point where things are fairly stable, I'll release 0.9 and then 1.0 after testing.

Mound Data Manager

Mound Website

For those who are unaware, this is an older project of mine. "Mound Data Manager is a tool that can manage data in the context of other applications. You can take snapshots, delete, and move data from many of your favorite applications."

Someone bugged me about this on IRC last night. As far as I know it's in a working state, but I'm going to open this up today and see what can be improved. Tentative list of goals:

• More application support
• Configurable snapshot storage (Ubuntu One, maybe)
• Triggerable snapshots over DBus
• GitHub migration

Commandeer

Commandeer Website

Another older project: "Commandeer allows you to run a command and lock the desktop for the duration of the command. It is useful for technical support situations or remote backup where you do not want the end user doing anything while the command is running."

This one worked right out of the box when I downloaded it, and there's not a whole lot to be done with it. Unity seems to interfere with the locking mechanism, so maybe I'll look into that. And there's the GitHub migration.

End

There you have it: goals. If you notice I'm not making good progress on any of these, feel free to send me an email or ping. It'll help me Get Things Done™.

OLF Day 1: Ubucon

Someone ought to have pictures up shortly as there were plenty of cameras about.

Things I have learned/realized/noticed today:

• Not many people interested in Ubuntu know what a LoCo is
• I should have brought the business cards in today, as everyone was scrambling to write down the LoCo URL
• Jorge's favorite arbitrary number is 56 (I'm probably the only one to have noticed this during his talk...)
• Convention center parking rates change dramatically depending on location. I should have checked the rates before entering the $11 garage and went to the $5 one next to it.
• Our banner, which I picked up this morning, looks awesome. Props to signscolumbus.com for a beautiful printing of a vinyl banner that should last us years, and only cost $25.
• The Chipotle near the convention center is closed on Saturdays, so I didn't go. Fatal flaw: today was Friday.
• Improvised talks seemed more engaging than planned ones -- they flowed based on the thoughts of the audience.
• I can't navigate I-270, even though I've lived pretty close all my life.
• The convention center kills cellphone reception pretty effectively.

I skipped the preparty to go home and get stuff ready for Saturday, but I got distracted by other things anyway. :P

If you're in your comfy Drury/Hyatt/whatever room right now reading this, be sure to stop by the booth tomorrow and say hi! I'll be in the brown "do it with ubuntu" shirt. Pick up a business card to remember to visit the LoCo when you return home. Seriously. We have 2000 of them. :)

I'm fairly tired, but I'm sure tomorrow will be even more exhausting (and awesome). I should probably go to sleep, considering I need to get up in 5 hours.

OLF Registration - Last call!

In under 2 days registration for Ohio LinuxFest will close. I can't stress enough how awesome this event is and how you (yes, you) should register and attend. You can't beat free.

We (Ubuntu Ohio) have printed a bunch of business cards to hand out at the event (any beyond). This will be a little experiment in letting people know about the LoCo. Take a look at them here:

http://www.flickr.com/photos/jpeddicord/4942412165/

(Aside: I'm about had it with Movable Type. Anyone have any ideas for alternative (Python/Django/PHP) blog software? I don't care for WordPress either but I'm willing to give it a shot again.)

SLS introduction

So what is SLS, and how can it be used to change settings? I've talked about it a lot, but what are the practical applications? This 5-minute screencast should give you a general idea: I go through the process of writing a quick SLS XML definition to show it all in action, from a developer point of view.

• Theora, low quality
• YouTube (H.264/WebM), high quality

The complete documentation and reference to SLS is available here and under /usr/share/doc/jobservice. If you're interested at all in using SLS for a service, I highly recommend you check that page out, even if just to skim.

If you maintain or help maintain any system service, be it a media streamer or a web server, do get in touch and we'll see how jobservice and SLS can apply to your service.

Call for testing: jobs-admin

Google Summer of Code ends this week, which indirectly means that jobs-admin is now ready for testing! Interested testers need only to add a PPA and install a package to begin. Within a few days the packages will be available in maverick universe.

sudo add-apt-repository ppa:jpeddicord/jobs
sudo apt-get install jobs-admin

Essentially, jobs-admin is a replacement for services-admin. Upstart support has been added, along with the ability to change settings on individual services. For example, you can tweak simple firewall settings or enable and disable Apport.

jobs-admin may be launched from the terminal, or can be found under System > Administration > System Jobs. We've hidden most jobs/services that are essential to your system, so ideally you shouldn't be able to break anything even if you wanted to. With that in mind, feel free to give it all a stress test. Shut off jobs you don't want, and change the settings of others. By testing this you'll also be testing jobservice, the daemon which powers it all. Think of jobservice as a "PackageKit" for system services: it's a generic backend to manage jobs no matter whether a system is running Upstart or a basic System V setup.

Bugs can be reported on Launchpad:

http://bugs.launchpad.net/jobsadmin

We're also open for translating:

• - for most UI elements
• - for job settings

Any and all feedback is welcome. We'll have a bugfix release in the next few weeks. I won't be responding to reports or feedback until August 16 (Monday), however.

For Maverick, you'll be able to install jobs-admin and have easy access to your system's services. The PPA will be maintained so Lucid users aren't left out. We're hoping to make this the de-facto utility (and framework) for managing services and jobs, and hopefully you'll see this in-place as the replacement for the missed services-admin in 11.04. I'll be working on getting these packages into Debian as well.