Contact information

• Your Name: Jacob Peddicord

• Email Address: jpeddicord@ubuntu.com

• IRC nickname: jacob

• Launchpad ID: ~jpeddicord

• Skype username: jacobmp92 (largely unused)

• Jabber: jacobmp92@gmail.com

• Webpage/blog: http://jacob.peddicord.net/

• Identi.ca: @jacob

• College-University: The Ohio State University

• Major: Computer Science & Engineering

Project

This project was originally intending to create a new services-admin from scratch; however after some mailing list discussions the previous one will be extended.

• Project Name: Upstart compatible services-admin

• Project Description:

  • The services-admin currently present in gnome-system-tools is capable of managing SysV-style services and is able to disable/enable them. However, it is unable to detect Upstart services and is also unable to configure service-specific parameters. I'd like to extend it with the following goals in mind:

    • Ease of use - it should display the necessities needed to manage services, while not getting too technical; much like it is now (though some technical knowledge is assumed if a user is messing around with services)

    • Properly secured using PolicyKit

    • Compatibility with Upstart and old-style SysV scripts
    • Configurable - should be able to change properties of services and reload them
    • Package and Launchpad integration - provide methods to uninstall the services' package and to report a bug on it

If you would be willing and able to do other projects instead, which ones?

Clipboard improvements would be another idea that interests me, having been a victim of the "copy, close, paste, realize nothing happened" model.

Why did you like this idea?

Upstart has replaced nearly all of the old boot scripts from /etc/init.d with newer, more concise jobs in /etc/init. The syntax of these files is easy to read, but powerful. That's the same idea in mind here: there should be an easy to use but powerful tool around to manage both Upstart jobs and older SysV scripts. It seems like something that would complement Upstart nicely.

In addition, I'm a server administrator myself and have messed around with Upstart & boot scripts. I'd love to be able to bring this functionality to the desktop by extending services-admin.

Please describe a tentative project architecture or an approach to it

There are a few main components that make up this idea, involving GNOME's gnome-system-tools and freedesktop's system-tools-backends:

• Backends - Communication with system-tools-backends; this is how services-admin currently works. Upstart functionality will be added to the services backend. This may require significant changes to the f.d.o implementation, which only allows for SysV-style services. Since we're only adding functionality, the changes should keep system-tools-backends' dbus API compatible with older software. In addition, liboobs will need to be modified to fit the changes in system-tools-backends.

• Management - Services should be able to: (handled by system-tools-backends & liboobs; the major change here would be adding Upstart capabilities)

  • be stopped & started

  • be restarted
  • change whether they run on boot (potentially blocked by lack of functionality in Upstart, will look into)
  • have their configuration reloaded
  • send other custom signals depending on the service
  • possible for a dependency tree to be calculated for upstart jobs

• Configuration - To configure service properties, I've thought of a few ideas. It'd be most logical to implement this in system-tools-backends & liboobs. One that would most likely work out would include shipping configuration "description" files, either with this project or with service packages themselves. These files would include information on:

  • Variables available for configuration and their types
  • Possible values/constraints
  • Where the actual configuration file(s) is/are stored
  • What needs to happen once the configuration is changed (force-reload, restart, etc)
  • Possibility to launch an external application to configure a service (big maybe here)

  • Translation for service descriptions & variables

• Package integration - Ask PackageKit which package owns the service, and provide an option to uninstall, update, or file a bug on it.

  • Provide option to uninstall/upgrade a package (via PK for upstream implementation and aptd/synaptic for Ubuntu)
  • Ability to report a bug on that package via ubuntu-bug (will ship this with an Ubuntu patch).
  • Will try to get as much functionality of this in the upstream product as possible, but some things may require Ubuntu-specific patches as stated in the above points.

Give us details about the milestones for this project

• First milestone (mid-June)
  • Upstart functionality should be in place in system-tools-backends and liboobs
• Second milestone (GSoC midpoint)
  • Basic configuration framework in place in system-tools-backends/liboobs
  • Configuration UI should be available in services-admin
  • Services should be able to be configured and reloaded
• Final milestone

  • Configuration UI & backend should be complete

  • Configuration descriptions for default system services should be available
  • Documentation should be available on how to ship a service configuration description

  • PackageKit integration should be finished (with appropriate patches ready for aptd in Ubuntu)

  • Polish, polish, polish

Why will your proposal benefit Ubuntu?

Both Mac OS X and Windows offer system utilities to administer services. Ubuntu used to, though with a rather limited applet. Having a full-fledged but easy-to-use application to administer and configure services would greatly benefit the user experience. Bringing back a graphical application would free up the need to use the terminal to configure services. It would make configuration quicker and safer. Instead of needing to launch a root editor to change a setting, a user would only need to set some options in PolicyKit-managed services-admin. It would make Ubuntu look more friendly to both the tweaking end-user and to the enterprise market, since many businesses may want to be able to easily disable services and set policies on what can be run.

Open Source

Please describe any previous Open Source development experience

I've been submitting occasional patches to Ubuntu for a while, and somewhat more frequently work on bug management. I've created some projects of my own, including Commandeer (Vala/GTK+) and Mound (Python/GTK+), both of which I've received merges on and eventually plan on getting into the archives. I've already packaged gfire for the archives, and have worked on other packages as well.

Why are you interested in Open Source?

Who isn't interested in open source? Seriously, I've always been peeved by the fact that I have to pay to use the computer I bought, and I can't even change it. The open source community has always appealed to me, so much that a few of us have created a site called FOSSwire to write about it (though my activity there has declined lately as I've been involved in other areas). I love the fact that if I make a mistake or need help, there's a whole community of developers who know just what to do. I used to write closed-source applications on Windows years ago, and I can definitely say it is much more fun to stay open.

Availability

How long will the project take? When can you begin?

It will likely take the entire duration of GSoC. I know a good amount about Upstart, GTK+, C, and a little GObject, but I still will need to research methods of managing services, PolicyKit, and effective communication over DBus. I can begin as soon as the timeline allows, unless we're actually allowed to start earlier. I will have two weeks of class and exams left on May 24, but that hasn't affected my development work in the past.

How much time do you expect to dedicate to this project? (weekly)

Considering the fact that I like to write code in my free time, I'd say a very good amount. I'd be able to work on it at about a 9-5 pace (so about 35 to 40 hours per week). It may be less during the first few weeks as I finish up classes.

Where will you based during the summer?

At home (Ohio; -0400 UTC) with a not-so-reliable connection, but it hasn't been a problem when working on code or collaborating in the past.

Do you have any commitments for the summer? (holidays/work/summer courses)

I'll be on vacation the second-to-last week of July (the week after midterm evaluations). I may have Internet access during that time, but wouldn't count on it.

Please designate a back up student (in case you need to withdraw your application)

Do not have one at the moment; I highly doubt I'd have to withdraw. Can definitely find someone to work on the project if something turns up.

Other

Have you ever participated in a previous GSoC? (describe your project)

No.

Have you applied for any other 2010 Summer of Code projects? If yes, which ones?

I have not; this is my first SoC so I'm still trying to get things straight before applying to things en masse.

Why did you apply for the Google Summer of Code?

I've always wanted to try out an SoC project since it was announced, but this is the first year I'm actually eligible.

Why did you choose Ubuntu as a mentoring organisation?

I've been using Ubuntu since 2006, but have never been actively involved in development. I've been pretty involved in the community and have had several stabs at patches, but haven't had the chance to do some real work. I think it's time to change that.

Why do you want to participate and why should Ubuntu choose you?

• I'd like to help out in a way that's going to make peoples' lives easier.
• I like to code.

• I've been active as an Ubuntu Member in the Ohio LoCo and on the Ubuntu Forums staff, and now I'd like to try development itself.

• I've got a plan for action and the will to implement it.
• I don't miss deadlines.

Thanks for reading this document; it's a bit on the lengthy side but I hope you enjoyed it. If you have any questions or would like to know more about this proposal, shoot me an email, shout at me on identi.ca, or poke me on IRC.