Next week we will hit Feature Freeze, by which time we “stop introducing new features, packages, and APIs, and concentrate on fixing bugs in the development release”. This also means that new upstream versions (if they not part of on the release team’s list of exceptions or pure bug fix releases) will need to get a freeze exception from the release team. This is also a reason why Daniel Holbach called for a “Sponsorship Friday“, so the queue of uploads which need code review is emptied again.
Matt Fischer wrote an interesting article about how to write a LightDM greeter. The post is really well done, explaining how LightDM works internally and how to get the greeter done easily.
We are excited to let you know about the Ubuntu Global Jam, an event where Ubuntu LoCo Teams around the world meet, have fun and together make Ubuntu better. Be it through translations, work on bugs, documentation, testing, packaging or whatever else. Check out the list of participating events to find if there’s something happening near where you live, or start an event yourself!
Can’t see the video? Click here.
Things which need to get done
If you want to get involved in packaging and bug fixing, there’s still a lot of bugs that need to get fixed:
- There’s Merges that need to be done (main, restricted, universe, multiverse).
- Also is the Ubuntu Mozilla team looking for help, so if you’re excited about Mozilla and what’s happening there, join IRC, talk to the guys on #ubuntu-mozillateam on irc.freenode.net.
- And then there’s Security bugs you can take a look at, the team is a friendly bunch and they’re incredibly helpful in getting your patch reviewed.
- There are bitesize bugs.
- Also did John Lea from the Ubuntu Design team talk to us and mentioned that there are bugs up for grabs, where the design has been decided on and the implementation might need YOUR help. If you want to help improve Ubuntu’s UI, have a look at these!
Spotlight: Kubuntu, alive and kicking
Benjamin Kerensa and Daniel Holbach briefly interviewed some of the Kubuntu developers to get an idea where things stand with Kubuntu.
The announcement that Canonical employee Jonathan Riddell would soon focus on goals other than Kubuntu maintenance has been widely discussed in the media, so first we asked the team, if they would like to add anything to these discussions which had been missed. Jonathan Riddell started out by saying that “pulling the plug” as many headlines have put it was too harsh and that Kubuntu will get the community support it always has done. Also he pointed out that Kubuntu did pleasingly well during 11.10 when he also wasn’t working on it.
We asked if the lack of you being involved full time would have any noticeable impact. Jonathan responded and said that he does community management, so nudges people towards tasks that they are capable of, and fills in areas of Kubuntu that are sometimes neglected, such as ISO testing and that these tasks will have been done by others.
As many readers probably don’t know how Kubuntu is put together, we asked how Kubuntu development has worked up until now. Rohan Garg gave us an overview: Basically, the Kubuntu team deals with the KDE and Qt packages in the Ubuntu archive, so whenever a new release is about to be made the team gets the source tarballs a couple of days before release and the team of ” Kubuntu ninjas” get cracking. They build, patch, and see to it that everything works as expected before release day, reporting any build issues upstream and getting tarballs respun is part and parcel of the job. Sometimes it happens that everyone is busy which causes delays in the release. Once the Kubuntu release is out, packages are usually backported into the Ubuntu backports repositories for the current stable release. The Kubuntu ninjas are also responsible for other KDE packages such as Amarok which are not part of the standard KDE release and as Jonathan Riddell pointed out that there is Qt and related bits too and added “with luck we can do some feature development (which is mostly specced out at UDS)”.
Testing is important as well. Jonathan mentioned ISO testing and Philip Muškovac explained that before stable release updates are pushed out, testing is done through public PPAs. Rohan and Philip went on and described how most of Kubuntu’s bug work is being done upstream: KDE bugs are directly reported in the KDE bug tracker, as KDE applications have their own bug/crash handling framework. Philip added that it would be great to have more contributions to bugs in Launchpad, so they can be forwarded to Upstream in a more timely fashion
Next we asked what’s in the cards for Kubuntu 12.04. Philip explained that the introduction of KDE 4.8 took a lot of time and that he is still supporting the Oxygen theme for GTK3. Rohan mentioned that a new IM client is being packaged right now, using the Telepathy framework. The packaging is almost done and testing will go on for a week before they enter the archive. Also was Rohan proud to admit that he is going to apply for Kubuntu upload rights!
It is interesting to note that Philip and Rohan both mentioned that the withdrawal of “official support” would actually make the development of Kubuntu easier: up until now all packages for the Kubuntu CDs had to be in the main repository, which requires a thorough investigation of the code. From now on Kubuntu bits could come from main and universe.
It is absolutely possible to contribute to Kubuntu and the team has enough tasks lined up, so you can help out. If it is triage of bugs, ISO testing, documentation or packaging: everyone is welcome to contribute and get involved. Jonathan mentioned that it is important that you are a “motivated self starter”, but that the fine people in #kubuntu-devel can help you out if you get stuck. The Kubuntu wiki page has more details.
- Read the Introduction to Ubuntu Development. It’s a short article which will help you understand how Ubuntu is put together, how the infrastructure is used and how we interact with other projects.
- Follow the instructions in the Getting Set Up article. A few simple commands, a registration at Launchpad and you should have all the tools you need, and you’re ready to go.
- Check out our instructions for how to fix a bug in Ubuntu, they come with small examples that make it easier to visualise what exactly you need to do.
Find something to work on
Pick a bitesize bug. These are the bugs we think should be easy to fix. Another option is to help out in one of our initiatives.
In addition to that there are loads more opportunities over at Harvest.
Getting in touch
There are many different ways to contact Ubuntu developers and get your questions answered.
- Be interactive and reach us most immediately: talk to us in #ubuntu-motu on irc.freenode.net.
- Follow mailing lists and get involved in the discussions: ubuntu-devel-announce (announce only, low traffic), ubuntu-devel (high-level discussions), ubuntu-devel-discuss (fairly general developer discussions).
- Stay up to date and follow the ubuntudev account on Facebook, Google+, Identi.ca or Twitter.
(Posted here first.)