Tuesday

The first session I attended Tuesday was the Community Roundtable, in which we discussed Team Reports and Planet Ubuntu, amongst some other things. It was said that for some it is not very clear how to add the Team Reports to the wiki in the correct fashion. To solve this the documentation will be improved, and we also may see dedicated website for submitting Team Reports. I remarked that another language is another barrier; in Ubuntu NL the most important argument against writing Team Reports was that we thought we had to write them in English. However, I have been told that it is not required to publish the Team Reports in English. This will make it a lot easier for us to write down our activities.

We also talked about Planet Ubuntu. A number of people, including me, expressed the wish that all posts on Planet Ubuntu get a name attached. It will be looked into how to make it possible to also make the name of the authors show up next to aggregated posts from the Canonical Design Team. It is also very possible that we will move away from PlanetPlanet, since that is an orphaned project, and even the original author has told people to move to something else.

The Indicator Datetime and Indicator Session were very short; it is mostly bugs that need to be fixed and polishing that needs to be done. Also, Ted Gould likes Texas so much because there are no naturally occurring lakes, save for the one that was created when a beaver built a dam somewhere.

During the plenaries I spend some time trying to figure out what is going on with this Packard Bell EasyNote MZ35 laptop. I’ve got this annoying bug that makes it that every time I am using wireless on this crappy RaLink RT61—the ‘rt61pci’ kernel module has been causing a lot of problems on this laptop and is probably to blame for this as well—and am not connected to a power socket, the laptop freezes.

In the ‘Encouraging game development on Ubuntu’ session Rick Spencer demonstrated his awesome work on creating a PyGame template for Quickly. Currently the command ‘quickly create ubuntu-pygame foo’ creates an actual working basic game, a nice start if you want to create a simple game. I didn’t follow the rest of this session a lot, so I can’t say much more.

Next was a really great session about the One Hundred Paper Cuts project. We should be really thankful to the wonderful, wonderful work Vish has done for this project last cycle. Without his tremendous efforts we wouldn’t have got nearly as many paper cuts solved as we did for Maverick. For the Natty cycle we want to make sure he gets some help. At least I plan on doing more work here. We are making some changes to the way we work on improving the package descriptions and are planning some other improvements to the project as well. More of that later, as I think this deserves a blog post of its own. One thing we will change I can say is that we will allow paper cuts to be reported against more applications, even some that are not in the default installation.

The last session of Tuesday was about the Adopt-an-Upstream project. This pet-project of Jorge will become more visible as we plan to make more people explicit Upstream Contacts who are currently already doing similar tasks. More of this will probably be announced in a blog post that Jorge will most likely write about this. (Right, Jorge?)

Wednesday

The first session of the day I attended was more of an informative session explaining the different technologies on which Unity is built. Something new I learned is that Unity will be a plugin of Compiz, just like Scale or Expo.

The ‘Launchpad for Upstreams’ session was a a really useful one, mostly because it allowed different ‘stakeholders’ to share their thoughts on Launchpad’s behaviour regarding upstreams and propose some optimisations. An exiting feature that was announced during this session was something that the developers have been working on for the last few months: we will see options on Launchpad to set the mail notification level in bugs and the possibility to subscribe to bug searches soon. Great news!

Here I would have talked about the plenaries of today, and the other sessions of Wednesday. However, because I am very tired, it is very late already and there weren’t many very important sessions for me I am skipping this. Apologises in case you were interested.

The last session of the day was about the Bug Squad’s documentation. Currently there is way too much text and there are way too many pages. This needs to change. It will be a lot of work, and this session as only a first discussion. We will probably see all current documentation moved to some archive, and then we will start the documentation from the ground up, moving over the useful pieces of text and designing an understandable and maintainable documentation structure. Stay tuned for more.

See you tomorrow.

You improve your relation with a project if you invest in it, and that is good for the quality of the project and Ubuntu. I would like to make you aware of a great way of being nice to upstreams: Adopt-an-Upstream. Slick name! But what is it? It is part of something a group of people from the community team lead by Jorge Castro have been working on ince the last UDS. The goal was to make it easier for upstream developers to find out how Ubuntu works and to improve the relations and synergy between up- and downstream.

At the wiki a starting point was created for upstreams where they can find an overview of the information that matters to them. Furthermore, a guide was created for upstreams that would like to get included in Ubuntu, but would like an overview of the requirements, the dos and the don’ts.

For members of the Ubuntu community there is something else: Adopt-an-Upstream is a way of taking care of a specific project that is included in Ubuntu. It’s mainly about being the communicational glue between up- and downstream. A comprehensive list of tasks:

• watch what’s going on upstream
• make sure new releases get to Ubuntu
• forward patches from Ubuntu to upstream
• communicate release schedules and announcements from Ubuntu to upstream

Summarised: act like a bridge between Ubuntu and the upstream project. Do you have an application you really like, or you really know a lot of, please consider to adopt it. Of course you don’t have to do it all on your own. Especially for large — be it in size, functionality or the number of bug reports — applications this can be a burdensome task. Those applications can be adopted by a group of people.

Next week Thursday 11 March at 17.00 UTC and on Thursday 18 March at 23.oo UTC Jorge Castro and I will be giving a one-hour session in #ubuntu-classroom at Freenode about Adopt-an-Upstream. We will explain the project more thoroughly and show how you can help out. Also, we will mention the Adopt-a-Package programme, which could be considered a part of Adopt-an-Upstream. If you consider getting involved in either one of these projects, please join one of the two sessions!

Questions? Please leave a comment!

Every day a lot of new bugs are reported on Launchpad, adding to the number of open bugs reported against Ubuntu. Currently there are 81259 open bugs in Ubuntu, of which 43775 are in the ‘New’ state. This means that roughly 54% of all open bugs in Ubuntu are not or were barely touched and when this post will have been published the number is already larger. When handling such large numbers of bug even the omnipotent BugSquad can’t keep up. How can we make sure the important bugs don’t get lost in this superabundance of support requests for writing good defect reports?

If you’re working with something — in the case of Adopt-a-Package an application — you like, you’re more productive. If you work on something you can keep an overview of, work is easier. This is what Adopt-a-Package purports. You choose an application you’re familiar with, or particularly fond of, and focus on getting it into shape on Launchpad. What does this mean? A small list:

• Triaging previously untriaged — ‘New’ — bugs
• Making sure no bugs are forgotten
• Moving Confirmed bugs to Triaged
• Forwarding bugs upstream

There are several ways to tackle the adoption. If you would like to adopt something as big as GDM[1] you’ll have a hard time if you’d try to do it all on your own, unless you have a lot of spare time. In such cases it’s better to form an AdoptionTeam and attack the bugs together with some other people. Smaller applications like ‘gedit‘ can be handled by one person, although it largely depends on your personal preferences and the amount of time you’re able or willing to spend on triaging. Of course you could always look for an existing group to join. As a matter of fact, I’m still looking for some more people to help out with Nautilus.

Adopt-a-Package is thoroughly explained on its wiki page, and it is that page you should use as your primary source of information. On this page you find a list of currently adopted applications and applications that we’d really like to see adopted. When you decide to adopt an application, whether you do it with a group or on your own, please check this page first to make sure you’re not duplicating efforts. After you’ve made up your mind about what you’re going to adopt, please add your name and the application to the list and notify the BugSquad maillist.

Are you interested but still have got some questions now you’ve read this? Don’t hesitate to leave a comment or drop by in the #ubuntu-bugs IRC channel. Also, in March there will be two sessions about Adopt-an-Upstream in #ubuntu-classroom, one by me at 4 March on 17.00 UTC and one by Jorge Castro at 18 March on 23.oo UTC. You can find them listed in the Ubuntu Classroom schedule.