Results 1 to 10 of 27

Thread: Contributing to Karmic Koala

Hybrid View

  1. #1
    Join Date
    Sep 2007

    Contributing to Karmic Koala

    Karmic Koala (9.10) will be the eleventh release of our favorite free open source operating system, Ubuntu. With the first Alpha release already out the door, now is a good time to recap what we can do to help make Karmic a quality release.

    It has been said that Ubuntu, and the wider FOSS ecosystem contributes in a gift economy. Countless hours of work by human beings across the globe has been gifted to you. All people, of any skill level, have a way to gift back to the ecosystem.

    First Things First

    * Get a Launchpad account if you don't already have one. You'll need it to report and track bugs, do translations in Rosetta, track support requests, and share the karma. Launchpad is an excellent central hub for almost all your contributions to Ubuntu. Register here.

    * Familiarize yourself with how Ubuntu development works, at least roughly. This will help you contribute more efficiently, and prevent many uncalled for misunderstandings. An excellent place to start is the Ubuntu Development page in the wiki. Even a brief look at the main page will give you a rough idea of how the pieces fit together, and it will help if you go deeper. If the puzzle in your head has missing pieces, don't hesitate to ask questions on how things work. The Ubuntu Open Week is also a good opportunity to dive a bit deeper into Ubuntu.

    * Review the Karmic Release Schedule, to plan ahead when and what you can contribute at this point in the development cycle.

    * If you're confused about and/or having too many problems with the development version and don't exactly feel on top of things, don't run it for the time being. The Ubuntu development process is a tough ride, tougher than most distros, due to the cutting edge technology policy and the fixed development duration that's tightly packed with radical changes; if at any point you decide that you can't bear with it, drop it until a more stable phase, a milestone release, or entirely. Karmic will be a development version until October 2009, and is prone to major breakage at any point. Do not rely on it as your main operating system. If you decide to test it, be aware that you're risking being left without a working operating system, and data loss.

    Reporting Bugs

    Bug reporting is one of the most accessible, and yet most beneficial ways in which everyone can contribute. It's a good idea to start reporting bugs as early as possible, since towards the later stages, especially past BetaFreeze, focus will most likely shift towards critical bugs only. Whenever you encounter a reproducible malfunction, file a bug report. It's a good idea to start a thread in the development forum before submitting your report, to discuss it with others who may have experienced it, to make sure it's genuine. And it's very important that you do a search for the bug before submitting it; duplicate bugs make life more difficult for everyone. It's practical to keep the URL structure for the source package bug pages (where you can search for bugs in them) in mind:


    Take a look at the Reporting Bugs page in the wiki to learn more about the procedure. The best practices wiki page also contains some useful information. Remember, how a bug is initially reported can have a huge effect on how it's handled and how quickly it gets fixed.

    Finding the right package is important when filing a bug report. This makes sure that the right developers will see your bug report.

    Apport is very handy in gathering technical information for bugs. One way you can use Apport is through the "ubuntu-bug" command. Simply type

    ubuntu-bug packagename

    in a terminal, where "packagename" is the name of the (binary) package you want to report a bug in, and Apport will be triggered to collect basic relevant information (such as release and package versions) and attach it to your report. This makes life easier for everyone (bug reporters, triagers and developers) by sparing them the time and effort needed for establishing the information Apport can automatically collect through dialogue.

    If you've reported a bug directly through Launchpad, and want Apport to collect the information afterwards, use apport-collect:

    apport-collect bugnumber

    will trigger Apport to attach the required information to the bug report you specify with "bugnumber".

    When you need to provide in-depth technical information that's beyond the scope of Apport, you'll find the debugging guides useful. The more information in a bug report, the easier it is for a bug triager or developer to get to the bottom for it.

    Please keep in mind if you install unsupported software or tweak the configuration items of your install beyond a reasonably supportable state, do not report bugs. In such a case you should be mindful that you are doing your own support of your own configuration. People who want to contribute towards Ubuntu testing need to keep their configuration in a supportable state.

    Triaging Bugs

    If you have enough dedication to go a step beyond reporting, this is where you're needed.

    Triaging bugs consists of the following:

    • Responding to new bugs as they are filed
    • Searching for duplicates in the bug tracking system
    • Forwarding bug reports to their upstream authors, when applicable
    • Cross-referencing bug reports from other distributions
    • Classifying bug reports by package
    • Prioritizing bugs
    • Expiring old bug reports

    Since new bug reports never stop coming, there are never enough bug triagers. It's an excellent way to help out that's much appreciated, and it will teach you a lot about how Ubuntu works. Anyone can help triage bugs, but you might also want to join the Bug Squad. After you've triaged bugs for a while, you can become a member of the Bug Control team, where you'll be allowed to change "Importance" and "Milestone" values of existing bugs.

    When triaging, it's important to understand bug statuses. For instance, confirming a bug means moving the status from new to confirmed, not simply say its confirmed in a comment in the bug.

    And regardless of whether you've worked on bugs before or not, don't miss the Hug Days!

    Linking Upstream Bug Reports

    Linking upstream bug reports to existing Ubuntu bug reports is an important way to help get bugs fixed.

    This blog post by Jorge Castro explains why, and this wiki page shows you how.

    Testing ISO Images

    The ISO Testing Team tests daily ISO builds that lead to milestone CD images before the milestones are officially out, making sure they work as intended. To join the team and help out, follow the instuctions on the team's wiki page, and apply to join the team on Launchpad.

    Submitting Ideas For New Features

    Ubuntu Brainstorm is the best place for users to suggest new ideas and see what others are talking about.

    At the start of each development period, a developer summit is held, where plans for the upcoming release are evaluated. The summit for Karmic will be held in Palau de Congressos de Catalunya, Barcelona, Spain between 25-29 May 2009.

    Some ideas can be quickly implemented, while others can require a great deal of discussion or development work. Even a seemingly simple idea can be complex to implement if it affects other aspects of the system. Changes to the default look or behavior of the base system are always controversial and may cause extensive discussions.

    A minor change can often be described in a bug report. The issue may actually be a bug (a fault in existing software). A simple change can be expressed as a 'wishlist' bug. For more complex changes we need to write a 'blueprint'. Blueprints (a.k.a. "specs") are documents suitable for developers to study and act upon. These should usually only be written by developers actively working on realizing the idea.

    Take a look at the list of existing specs for Ubuntu first. If you can write concise, workable specs yourself, go ahead and submit them. If you can't, taking a look at some well written and accepted specs, or the spec template may help.

    A lot of the ideas submitted so far either already have corresponding specs (some being worked on), or have already been proposed in another form by others, so please do a Brainstorm search, a spec search, and a forum search to see if what you're proposing has already been proposed by someone else, or is already being worked on.

    Doing Translations

    Ubuntu puts a special emphasis on the right and ability of all its users to comfortably use Free software in their native languages, so translations have their special place. If you're fluent with a second language beside English, your contribution to translations in Rosetta, Launchpad's translation module, will be valuable. With Rosetta's web interface, you can translate as much as you want, at any time, in any package.

    Make sure you're familiar with the software you translate, for your translations to have as much sensitivity on wording context as possible. The freedom of multiple translators to non-linearly edit translations at will can bring problems with it as well, such as consistency; it's a good idea to keep in touch with your fellow translators in your language's translation team in Launchpad and/or the upstream contacts for the software you're translating to tackle such possible difficulties.

    Bug Fixing, Code and Packaging Work

    There are various ways and venues through which you can contribute code and packaging work to Ubuntu.

    Doing Design

    If you do graphics and user interface design, you can get involved in one of the Ubuntu-related community artwork projects.

    Writing Documentation

    If you can write good documentation, you can work with the Documentation Team, or by yourself on the community documentation.


    The idea with 5-A-Day is simple - everyone in the Ubuntu community works to tend to at least five bugs every day, and to make it fun, we have produced some tools and rankings to make those 5 bugs count.

    See the 5-A-Day wiki page for all the info!

    (This guide originally was produced by 23meg in the Gutsy cycle. Since, andrewsomething refreshed it and many other people have contributed to it. Please add any additional information that you think is important for people to know about in the comments. Thanks!)
    Last edited by 23meg; June 16th, 2009 at 11:15 PM.
    He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.

  2. #2
    Join Date
    Feb 2007
    Ubuntu Development Release

    Re: Contributing to Karmic Koala

    Quote Originally Posted by Nullack View Post
    ... now is a good time to recap what we can do to help make Jaunty a quality release.
    "Jaunty" should be "Karmic"

  3. #3
    Join Date
    Sep 2007

    Re: Contributing to Karmic Koala

    23meg says he has some improvements he's editing and I felt that until we kinda have a consensus about the content it wont confuse new users by it being sticky.
    He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.

  4. #4
    Join Date
    Jun 2007
    Ubuntu Development Release

    Re: Contributing to Karmic Koala

    Thanks for updating this again, Nullack!

    Could you add something to Bug Fixing, Code and Packaging Work for me?

    We're now having regularly scheduled Packaging Training sessions. These are aiming to be short (~15-30 min) hands on sessions followed by Q&A.

    More info:

    Wiki -
    Blog -

    Maybe we could start a wiki page of this post? It would make getting it up with each new release easier and allow for more collaboration.
    Last edited by andrewsomething; May 18th, 2009 at 03:00 AM.

    Community Manager @ DigitalOcean
    You're more likely to get answers from me over on AskUbuntu these days.

  5. #5
    Join Date
    Mar 2005

    Re: Contributing to Karmic Koala

    Quote Originally Posted by andrewsomething View Post
    Maybe we could start a wiki page of this post? It would make getting it up with each new release easier and allow for more collaboration.
    That's what I was thinking as well, but one problem that will make it somewhat less efficient than it can be is that wiki and forum markup differ.

  6. #6
    Join Date
    Jun 2008
    Ubuntu Jaunty Jackalope (testing)

    Re: Contributing to Karmic Koala

    Updating right now, thanks for yhe warnin Nullack was very busy setting up a geocache team so I almost missed out on the fun. Lets see what Koala brings us, I find it adorable creatures so lets hope something of that sticks to the distro.
    The cloud is evil. Ubuntu One > /dev/null !!!


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts