Project Maintainers Required

Project Maintainers Required

Yesterday I announced that the new [Severed Fifth](https://www.severedfifth.com/) website is launched on Monday, and with it will begin the second phase of the project and the build-up to the second album. For the first album I ran out of steam as I had just signed up to do [The Art Of Community](https://www.artofcommunityonline.org) for O’Reilly and this sucked up all of my spare time. I don’t want to make the same mistake again.

As such, I am keen to hand over some of my projects to new maintainers who can be sure to give them the time and focus that they deserve. Today I want to share some of the next next steps I would ideally like to see to provide some food for thought, and appeal for volunteers to take the reigns in these projects:

### Acire

[Acire](https://launchpad.net/acire) is the project I created to produce a solid library of Python Snippets to make it easier for new developers to get started with the platform. The project has been pretty popular and I am keen to see it continue to grow.

Right now Acire has a good feature-set to browse and run snippets, but I would love to see it continue to develop and include the following:

* **Dependency Checking** – when running a snippet that requires a module that you don’t have installed, Acire should tell you and provide a one-click installation of the required module(s). [Ed has a branch](https://code.edge.launchpad.net/~edgar-b-dsouza/acire/snippet_dependency_res_2/+merge/24813) that he started, and this seems like a good start on this solution.
* **Async Documentation Checking** – right now when Acire loads documentation links it stalls due to it’s non-async loading of the docs URL title. This causes significant problems if you are not connected to a network. It would be good to use GIO to solve this.
* **Better Searchability Of Snippets** – I would love to see (a) a search box to do a text search across all snippets and (b) see a better taxonomy of snippets. There are two cases here: (1) I want a snippet that is part of a specific module, and (2) I want a snippet to help me with something (such as playing music). Today you can only search by category (which is mainly categorized by module name). This could be greatly improved.
* **Multiple Language Support** – while I love Python, I would love Acire to be able to support multiple languages. I think the most elegant way to do this is to have a *language pack* for each supported language. Today you get Python content with the `python-snippets` package, but I would love to see `c#-snippets` as an example.

Would you like to take the reigns with Acire? If so, drop me an email to jono AT ubuntu DOT com.

### Python Snippets

For [Python Snippets](https://launchpad.net/python-snippets) I would like to grow a team of reviewers. Right now I approve all merge proposals and merge them into the branch (which is used to generate the daily PPA), but I think it makes better sense to distribute this work across a number of contributors that can communicate via a mailing list.

If you are interested in joining this team, drop me an email to jono AT ubuntu DOT com.

### PyJunior

[PyJunior](https://launchpad.net/pyjunior) was a project [I wrote in a few hours while on vacation](https://archivedblog.jonobacon.com/2010/04/08/making-programming-easier-for-kids-with-pyjunior/). The whole point is to make programming for kids much easier, and although simple, the program is off to a good start.

PyJunior *really* excites me. It holds so much potential to really introduce kids to Python and all the fun you can have with it. Some plans I have had for PyJunior include

* **Integrated Kid Friendly Docs** – I have a dream for the documentation in PyJunior. You click the *Help* button and a window displays a list of *Recipes*. These are tutorial documents that outline how to do something fun such as make a calculator or a game. Each recipe not only explains how to write the code in simple kid-friendly steps, but also includes a button next to each code snippet that will paste it into the editor. I think it could be awesome to have a PyJunior Docs Team that produces these docs, and that the Recipe Browser would grab them off the Internet to save having to ship them with the app. This could really open up the world of programming for kids.
* **Sharing Programs** – I includes a Share button in PyJunior that is switched off by default, but the goal was to create one-click way in which you can share a program with your friend. Kids need to be able to easily help each other with programs and this would provide a means for one kid to share his/her program with their friend who can then help them do something or fix a problem.
* **Interactive Tutorial** – I would love to have written an animated interactive tutorial (like the first level of a modern game that explains how the controls work) that explains how the interface works.

Would you like to take the reigns with PyJunior? If so, drop me an email to jono AT ubuntu DOT com.

### Moving On

If any of these projects sound exciting to you, do get in touch. I want to make sure that each has a competent maintainer who has the time to commit to the project, so I will go through a short evaluation for each. Thanks in advance to everyone who volunteers to help. ๐Ÿ™‚

Project Maintainers Required

Severed Fifth II

For those of you who are curious about the next steps for [Severed Fifth](https://www.severedfifth.com/); my Creative Commons music project:

* On Monday I launch the brand new website.
* Writing for the second album is nearly complete and I will be streaming the entire recording sessions live.

I have created a new [Severed Fifth Twitter account](https://twitter.com/severedfifth), so [go and follow it](https://twitter.com/severedfifth) to keep up to date with the latest. ๐Ÿ™‚

At Home With Jono Bacon

At Home With Jono Bacon

Just a quick FYI: tomorrow I will be hosting my weekly [At Home with Jono Bacon](https://www.ustream.tv/channel/at-home-with-jono-bacon) videocast at **11am Pacific / 2pm Eastern / 6pm UTC** and I will be covering the following topics:

* HOWTO: Upgrading To Maverick
* HOWTO: Filing Bugs
* Community Team Plans for Maverick
* Q+A

I hope to see you all there [at the live recording](https://www.ustream.tv/channel/at-home-with-jono-bacon)!

At Home With Jono Bacon

Why Launchpad Rocks: Reviewing Contributions Is Simple

*This article is [part of a series of articles](https://archivedblog.jonobacon.com/category/why-launchpad-rocks/) about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is*.

Open Source is fundamentally driven by *gifts*. People contribute translations, documentation, artwork, code and more. Many of these gifts are made available in the form of *patches*; fragments of content that can be applied to other chunks of content to apply new features, resolve issues or add value in other ways. Patches are wonderful contributions. their authors take the time to care about a problem and invest their expertise and time in producing a solution that everyone can share and benefit from. As such, we should treat these patches with the due care and attention that they deserve.

Something we found in Ubuntu was that we were getting so many patches submitted that many were being lost in the mix and were not getting reviewed and applied if appropriate. This goes against the grain of a *gift* – we should always review these gifts with a strong sense of care and timeliness. The situation was not driven by carelessness or malice, but instead a lack of visibility on these available patches for a given project.

As such, we worked to build a new feature into Launchpad to provide a simple way of looking at all submitted patches. It looks like this:

Accessing this is simple; just add `+patches` to the end of a Launchpad project address. As an example for [Zope](https://edge.launchpad.net/zope/+patches)

https://edge.launchpad.net/zope/+patches

This also applies to source packages in Ubuntu. As an example for the [Gwibber]() source package:

https://edge.launchpad.net/ubuntu/+source/gwibber/+patches

With each of these patch views you can order the patches by patch age, see the current status of the patch, and see it’s importance. This all provides a better way for these important contributions to be reviewed for the benefit of everyone.

**See a list of all of these Why Launchpad Rocks articles [here](https://archivedblog.jonobacon.com/category/why-launchpad-rocks/)**.

Why Launchpad Rocks: Working With Code Is Dead Simple

Why Launchpad Rocks: Working With Code Is Dead Simple

*This article is [part of a series of articles](https://archivedblog.jonobacon.com/category/why-launchpad-rocks/) about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is*.

One of the things I love about Launchpad is that getting, hacking, sharing, merging in code is *dead simple*. Much of this is because of it’s tight integration with the [Bazaar](https://bazaar.canonical.com/en/) version control system. Together it provides a *kid-in-candy-shop* level of awesome if you like to run and hack on code.

One of the things I love about Bazaar is that it is focused on simplicity, and having used CVS and Subversion in the past, and a little bit of git recently, I find Bazaar by far the most naturally connected with my workflow. The reason for this is that *I don’t want to care about version control*. I am not interested in it, I don’t want to learn it, I don’t plan on sending it a Christmas card; I merely want to learn enough to get code from somewhere, upload it somewhere and rock with it. Bazaar is well suited to my needs because it’s simplicity means that it doesn’t feel like a pain to use.

Getting code is simple. I can click on the *Code* part of a Launchpad project and Launchpad tells me what command I need to run to grab a branch. As an example, if I want to download code from the [Lernid](https://launchpad.net/lernid) project, I just run:

bzr branch lp:lernid

This gets me a branch easily, and I am ready to hack on it. when I have my feature or fix ready, I can then push it really easily with:

bzr push lp:~jonobacon/lernid/my-new-feature

…changing `my-new-feature` for whatever branch name I want to call it. At this point my branch will appear with the other branches in the Lernid project, so the other developers can download and try it. If I would like to ask the Lernid developers to merge it into their main trunk branch, I can *Propose It For Merging* in Launchpad which provides a user interface for the developers to review the branch, ask me comments, request changes and otherwise have a conversation about the proposed merge.

This all makes grabbing code, hacking on it, sharing it with others, and asking for it to be merged *dead simple*.

Not only this, but if you are interesting in contributing to Ubuntu, all source packages are held in Bazaar which means that the same tools and commands for working with code apply to working on one of the most popular Linux distributions too. You can read more about this [here](https://wiki.ubuntu.com/DistributedDevelopment/Documentation).

**See a list of all of these Why Launchpad Rocks articles [here](https://archivedblog.jonobacon.com/category/why-launchpad-rocks/)**.

Testing Indicator Application Menu Support

Testing Indicator Application Menu Support

In the Ubuntu 10.10 cycle we have committed to implementing application menus in the Ubuntu Netbook Edition release of Ubuntu. There are many benefits to this approach, but I will you to the [design rationale](https://design.canonical.com/2010/05/menu-bar/) that was announced recently. I personally think this is going to be a tremendously valuable feature and continues to optimize Ubuntu for screen real-estate.

To satisfy this feature, the Desktop Experience team have produced an implementation called [indicator-appmenu](https://launchpad.net/indicator-appmenu) which has been worked on by the always awesome [Cody Russell](https://blogs.gnome.org/bratsche/) and [Ted Gould](https://gould.cx/ted/blog). The implementation essentially re-routes application menus over dbusmenu so that they can appear in the panel; the technology is based on the same technology that drives the application indicator framework. Aside from the design rationale benefits, the implementation also supports GTK and Qt menus out of the box and will render Qt menus in GNOME with GTK widgets and vice versa. All in all I think it is hugely exciting work.

For the majority of applications that use standard menu widgets, applications should *just work* out of the box. We are though keen to test as many applications as possible to ensure they work and identify problem spots. Like the last cycle, this new code has been released very early for testing and improvements, and we are keen to have as many folks test, file bugs and where possible file patches to fixes.

To make this as simple as possible, [this page explains how to download, test and provide feedback](https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu). Importantly, you *don’t have to be running Ubuntu Netbook Edition to test – you can use the normal Ubuntu desktop edition!*. Packages are already available in a PPA for Lucid and we have listed all of the apps that could do with some testing. We have also includes instructions for how to file bugs for apps that have issues; this will make it easier to produce fixes. One important note: up until alpha 2 we are deliberately leaving the menus switched on in both the application and in the panel – this provides a great way to compare and contrast the normal app menu with the panel menu to ensure they are the same.

Thanks to everyone who participates in the testing; this is sure to make the Ubuntu Netbook Edition rock even harder. ๐Ÿ™‚

**[To get started testing, click here](https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu)!**

Maverick Community Team Plans

Maverick Community Team Plans

As many of you will know, I manage the Ubuntu Community Team at Canonical, which has horsemen Holbach, Castro and Planella in it. A large chunk of my job is to take into account the wide range of needs from our different stakeholders (community teams, Canonical teams, upstreams etc) and to flesh out a strategy for my team for each cycle. To do this I gather input and feedback from the team and these stakeholders and put together strategy that will guide the team’s work through the cycle. Today I want to share this strategy with you all.

Most components in this strategy includes a blueprint which itself includes a set of actions that outlines the goals for Maverick. The benefit of this approach is that you can subscribe to blueprints you are interested in and keep track of those projects as we work through them. If there are elements of these blueprints that you would like to contribute to and get involved with, do let us know. ๐Ÿ™‚

So, on with the blueprints. Please note: each of these blueprints is targeted for the Maverick cycle only and these are the blueprints that my team specifically is working on with assistance from the community – other Canonical teams are of course working on their own sets of blueprints. Also, this does not include all community blueprints: there are many blueprints that are not part of my teams expected deliverables.

### Ayatana

> **Socialize Indicator Application Menu with upstreams**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-global-menu](https://blueprints.launchpad.net/ubuntu/+spec/community-m-global-menu)

> **Continue work with upstreams on adopting application indicator technology**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-application-indicators-outreach](https://blueprints.launchpad.net/ubuntu/+spec/community-m-application-indicators-outreach)

### Daily Builds

> **Document the daily builds infrastructure and workflow**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-document-daily-builds](https://blueprints.launchpad.net/ubuntu/+spec/community-m-document-daily-builds)

> **Advocate, promote and enthuse the use of daily builds for a range of tasks**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-advocate-daily-builds](https://blueprints.launchpad.net/ubuntu/+spec/community-m-advocate-daily-builds)

### Developer Growth

> **Improve Harvest usability**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-improve-harvest-usability](https://blueprints.launchpad.net/ubuntu/+spec/community-m-improve-harvest-usability)

> **Improve Harvest speed**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-improve-harvest-speed](https://blueprints.launchpad.net/ubuntu/+spec/community-m-improve-harvest-speed)

> **Find opportunities for reducing the complexity of the workflow as a developer**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-development-workflow-review](https://blueprints.launchpad.net/ubuntu/+spec/community-m-development-workflow-review)

> **Create a graphic high-level overview of common development process**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-development-workflow-review](https://blueprints.launchpad.net/ubuntu/+spec/community-m-development-workflow-review)

> **Create initiative around Packaging Documentation and update the docs**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-packaging-docs](https://blueprints.launchpad.net/ubuntu/+spec/community-m-packaging-docs)

### Patch Review

> **Patch Review Process Review**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-patch-review-process](https://blueprints.launchpad.net/ubuntu/+spec/community-m-patch-review-process)

> **Patch Review Initiative**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-patch-review-initiative](https://blueprints.launchpad.net/ubuntu/+spec/community-m-patch-review-initiative)

### Upstreams

> **Launchpad upstream bug workflow improvements**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-launchpad-upstream-improvements-bugs](https://blueprints.launchpad.net/ubuntu/+spec/community-m-launchpad-upstream-improvements-bugs)

> **Launchpad upstream patch visibiity improvements**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-launchpad-upstream-improvements-patches](https://blueprints.launchpad.net/ubuntu/+spec/community-m-launchpad-upstream-improvements-patches)

> **Evangelize daily builds to upstreams**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-upstream-dailybuilds](https://blueprints.launchpad.net/ubuntu/+spec/community-m-upstream-dailybuilds)

> **Continued upstream contacts growth**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-upstream-contacts](https://blueprints.launchpad.net/ubuntu/+spec/community-m-upstream-contacts)

> **Organize Canonical presence at upstream events**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-conferences](https://blueprints.launchpad.net/ubuntu/+spec/community-m-conferences)

### Best Practice

> **Document and consolidate core community processes**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-process-improvements](https://blueprints.launchpad.net/ubuntu/+spec/community-m-process-improvements)

### Translations

> **Improve Translations Packaging for Help in Ubuntu Applications**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-improve-translations-packaging-for-help-in-ubuntu-applications](https://blueprints.launchpad.net/ubuntu/+spec/community-m-improve-translations-packaging-for-help-in-ubuntu-applications)

> **Translations Community Advocacy**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-translations-community-advocacy](https://blueprints.launchpad.net/ubuntu/+spec/community-m-translations-community-advocacy)

> **Translations Community Learning Content**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-translations-community-learning-content](https://blueprints.launchpad.net/ubuntu/+spec/community-m-translations-community-learning-content)

> **Translations Community Events**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-translations-community-events](https://blueprints.launchpad.net/ubuntu/+spec/community-m-translations-community-events)

> **Extend the translations status reporting**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-improving-translation-status-reporting](https://blueprints.launchpad.net/ubuntu/+spec/community-m-improving-translation-status-reporting)

> **Healthcheck for core translation teams**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-translation-teams-healthcheck](https://blueprints.launchpad.net/ubuntu/+spec/community-m-translation-teams-healthcheck)

> **Launchpad Translations Reporting API**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-launchpad-translations-reporting-api](https://blueprints.launchpad.net/ubuntu/+spec/community-m-launchpad-translations-reporting-api)

> **Developer education on localization**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-developer-education-on-localization](https://blueprints.launchpad.net/ubuntu/+spec/community-m-developer-education-on-localization)

### Software Delivery

> **Process for post-release updates**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-post-release-app-process](https://blueprints.launchpad.net/ubuntu/+spec/community-m-post-release-app-process)

### Infrastructure Improvements

> **LoCo Directory – Improved Events Handling**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-loco-directory-plans](https://blueprints.launchpad.net/ubuntu/+spec/community-m-loco-directory-plans)

> **developer.ubuntu.com**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-opportunistic-developer-outreach](https://blueprints.edge.launchpad.net/ubuntu/+spec/community-m-opportunistic-developer-outreach)

### Regular Cycle Activities

> **Tuition Week plans (Open Week, App Dev Week, Dev Week)**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-tuition-weeks](https://blueprints.launchpad.net/ubuntu/+spec/community-m-tuition-weeks)

> **Ubuntu Global Jam**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-global-jam](https://blueprints.launchpad.net/ubuntu/+spec/community-m-global-jam)

> **Release Parties**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-release-parties](https://blueprints.launchpad.net/ubuntu/+spec/community-m-release-parties)

> **Ubuntu Free Culture Showcase**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-free-culture-showcase](https://blueprints.launchpad.net/ubuntu/+spec/community-m-free-culture-showcase)

> **Maverick Governance Changes**
[https://blueprints.launchpad.net/ubuntu/+spec/community-m-governance-changes](https://blueprints.launchpad.net/ubuntu/+spec/community-m-governance-changes)

As you can see, we have quite a bit to keep us occupied in this cycle. ๐Ÿ™‚ If you want to watch the sausage being made, subscribe to the blueprints you are interested in, track out [burndown chart](https://people.canonical.com/~pitti/workitems/maverick/canonical-community.html), and do join us in `#ubuntu-community-team` on Freenode where we work together.

We look forward to seeing you there! Horsemen…roll out!

At Home With Jono Bacon

Why Launchpad Rocks: Great Bug Tracking

*This article is [part of a series of articles](https://archivedblog.jonobacon.com/category/why-launchpad-rocks/) about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is*.

Everyone has an opinion about bug trackers. I suspect my dad may even have an opinion, and I am pretty sure he has no idea what a bug tracker even is. The general consensus seems to be that everyone thinks that all bug trackers suck. A strong view, but one not entirely without merit given the fact that a vast majority of bug trackers do indeed suck. In the past I have mainly used Trac, SourceForge, Mantis and Bugzilla, and I have to say that I find Launchpad best suited to my needs and more importantly, most usable by my users who I expect to file a bug when something goes belly up.

I just want to zip through some of the reasons why I find bug tracking in Launchpad a breeze and well suited to all of my applications.

### Simplicity

Of course, simplicity is a relative term, but I genuinely find that Launchpad provides the easiest interface for reporting bugs from the perspective of an end-user, and provides the easiest method of triaging and managing bugs. In terms of reporting bugs, the process is as simple as entering a subject and body content of the bug report. There are the usual additional options, but these are buried away a little so as not to confuse end-users. Launchpad also includes an excellent dupe-search to help end-users find existing bugs, yet still mark that it affects them without them having to engage in the irritating “me too” comment.

Ubuntu has been an excellent project for stress testing the triage and management of bugs, with literally thousands of bugs flowing through the system. The Launchpad team have reacted well to this feedback and now Launchpad feels like a nimble and efficient system for triage and management. The interface is simple and uncluttered and provides easy access to the different attributes of a bug report. Not only that but it is simple to query different classes of bug to make it simple to provide targeted work-lists for developers.

### Bug Linking

One of the coolest features in Launchpad bug tracking is *bug linking*. Imagine the scenario that you work on a piece of upstream software that is shipped in three different distributions. The same bug could conceivably be filed against the main upstream project in Launchpad, as well as against the source packages for the project in each distributors bug tracker. This now means you have four different bugs that actually reflect the same bug, each with their own comment histories and possible patches.

The Launchpad team have produced a feature where you can link a bug in Launchpad with other bugs in Launchpad against different projects, and even link against bugs outside of Launchpad in Trac and Bugzilla. Launchpad can then pull the status and from these other bugs and reflect them in the main bug in Launchpad. This provides a way of consolidating these different bugs in one place which saves time and duplication of effort. The Launchpad team have produced a series of [bug tracker plugins](https://help.launchpad.net/Bugs/PluginAPISpec) for Bugzilla and Trac which can share the comment history for the same bug tracked both in Launchpad and an external tracker. What’s more, to help find low-hanging fruit, thereโ€™s a โ€œBugs fixed elsewhereโ€ report that shows which of your bugs are marked fixed in other communities.

### Fixes

Ultimately a bug conversation ideally leads to a fix. Launchpad has made it simple to bring bugs and fixes together. You can easily see any patches attached to a bug report and you can also jump straight to a list of all the bug reports, associated with your project, that have patches. This is ideal when new developers join your project; you can direct them at the list of outstanding unreviewed patches as a place to start.

For fixes that require more than a simple patch, you can link directly to the Bazaar branch (including imports from Git, Subversion and CVS) you’re working in, allowing everyone interested in the bug to watch your solution evolve or even download your branch, make their own changes and then upload them back to Launchpad for everyone to see. A single URL points to the latest version of the fix and a single command merges it into the project’s trunk branch.

### Extensibility

Anyone who has been in the software business for a while will know that no matter how much you try to pre-empt the needs of developers, developers will always end up writing their own tools and workflow that suits them best. In other words, give the developer the tools to write their own tools and they will do incredible things. I think providing this kind of extensibility really demonstrates maturity in the creators of a software product. It shows that the tools provider is keen to help the developer get the very best solution, instead of being overly protective about building every possible solution in to *their* interface.

The Launchpad team have produced an API called [launchpadlib](https://edge.launchpad.net/+tour/api) that provides a RESTful Python API that lets you manipulate data in Launchpad just like any other Python object. In terms of bugs specifically, launchpadlib lets you report, access, and manage bugs, and also provides the ability to authenticate your apps to Launchpad. This means you can write tools to interface with your bugs that meet your specific needs, be it easier ways to triage, generate reports, or even embedding a modified bug submission form into your project’s website. A good example of this kind of third-party work is [Bughugger](https://edge.launchpad.net/bughugger); a desktop front-end to Launchpad bugs and Apport, a tool for reporting bugs in Ubuntu that automatically gathers debugging information.

**See a list of all of these Why Launchpad Rocks articles [here](https://archivedblog.jonobacon.com/category/why-launchpad-rocks/)**.

Why Launchpad Rocks: Just Enough Goodness For My Project

Why Launchpad Rocks: Just Enough Goodness For My Project

Today I want to start contributing to a solution for something that has been agitating me for a while. That is, *simply not enough people know who wicked-cool [Launchpad](https://www.launchpad.net) is*.

I am what I would describe as an *opportunistic programmer*. I like to write programs in my spare time that are fun and interesting, and I like to share those programs with other people. I like to work together with other programmers to make these programs better so everyone who uses them benefits.

As such, I have tried a bunch of collaborative development websites. I tried SourceForge, I have used Trac, I tried setting up my own infrastructure, and ultimately I have always settled on Launchpad. The more I have used Launchpad the more I have discovered just how ideal it is for Open Source contributors to work together on software. Unfortunately, so many contributors have no idea of all this cool stuff that Launchpad can do. So, I am going to spurt a bunch of blog entries onto the Internet to help spread the word.

Now, let me be clear in my intentions and drive here. While I do work at Canonical, I *don’t* work on the Launchpad team. I am not responsible for building a Launchpad community. I am not responsible for telling people why you should use Launchpad, and the Launchpad team has not asked me to write these blog entries. Instead, I am writing these articles with my *opportunistic developer* hat on as opposed to my Canonical hat, and I hope you interpret these posts as such. ๐Ÿ™‚

I plan for these posts to mostly short and sweet and enough to get folks started in exploring a particular feature in Launchpad. I hope you like them.

## Just Enough Goodness For My Project

One thing I love about Launchpad is that it gives me just enough of what I need for a software project. Back in the old days I used to use SourceForge to work on projects. It felt like a ten tonne hammer to crack a very small nut. I struggled along with it’s overly complex interface, filled with features I was never going to use. Like many developers, I found myself battling more with SourceForge than actually writing code for my programs.

So, I decided to give Trac a whirl. I loved it, and we used to hack on [Jokosher](https://www.jokosher.org/) in Trac for that very reason. While Trac was great for providing code-hosting, viewing and a built-in wiki, it’s issue tracker didn’t really meet our needs for a bug tracker. It also provided no answer tracking or translations features. As such we decided to move over to Launchpad and [the project has been there ever since](https://launchpad.net/jokosher).

I feel Launchpad gets the right balance. It doesn’t overflow you with meaningless features that you will never use, but instead provides a well designed set of core tools that I have used for pretty much all of my projects. This includes:

* [Bug Tracking](https://launchpad.net/+tour/bugs) – a place to file bugs, triage them, attach fixes to them and manage them.
* [Code Hosting](https://launchpad.net/+tour/branch-hosting-tracking) – a place to store and view your code and manage those branches.
* [Translations](https://launchpad.net/+tour/translation) – a place where non-developers can contribute translations to your program.
* [Package Building](https://launchpad.net/+tour/ppa) – a place to build packages for Ubuntu and deliver them to users.
* [Specification Tracking](https://launchpad.net/+tour/feature-tracking) – a place to plan features to be used in projects.
* [Community Support](https://launchpad.net/+tour/community-support) – a place where questions can be asked and answered.

My projects use all of these features and this is most of what I need in a development forge, with the only additional features that could be nice being a wiki and possibly a testing tracker. Not only does Launchpad give me enough of what I need to be productive, but it also integrates all of these components. As an example, branches in the code hosting component can be attached to bugs in the bug tracker.

**See a list of all of these Why Launchpad Rocks articles [here](https://archivedblog.jonobacon.com/category/why-launchpad-rocks/)**.

IMPORTANT: Ash Cloud Travel Problems And UDS

IMPORTANT: Ash Cloud Travel Problems And UDS

With the [Ubuntu Developer Summit](https://wiki.ubuntu.com/UDS) beginning on Mon 10th May, some attendees may face travel disruption due to the [recent Eyjafjallajokull volcanic eruption and resulting ash cloud](https://news.bbc.co.uk/2/hi/in_depth/europe/2010/iceland_volcano/default.stm) which is affecting travel to and from some parts of Europe.

## FOR THOSE TRAVELING

For those of you who are traveling to the event, you should liaise with your travel agent and airline for up to the date information about potential travel delays. If you have been sponsored by Canonical to attend, you should check with the airline you were booked with for up to the date information. We are currently monitoring the situation and will email all sponsored attendees with any travel changes if required.

## REMOTE PARTICIPATION

We always provide remote participation facilities at UDS, and our IS team are ensuring that we can provide the best remote participation experience they can. You can find out details of how to participate [on this page](https://wiki.ubuntu.com/UDS-M/RemoteParticipation).

## MORE INFORMATION

Please consult your airline for the latest on the ash cloud’s impact on travel. The [BBC is also providing excellent coverage](https://news.bbc.co.uk/2/hi/in_depth/europe/2010/iceland_volcano/default.stm).