Ubuntu Conference: The LaunchPad workshop

Advertisement

The workshops began with an introduction by Mark Shuttleworth (right) and Carlos González, from the Secretaria de Telecomunicacions i Societat de la Informació de la Generalitat de Catalunya. Attendees included other government representatives, members of the Hispalinux community, the local press, and your roving LWN reporter.

Carlos explained that Mataró is located in Catalunya, where Catalan is the local language and the local Linux distribution is Càtix. Other regions in Spain have their own language and culture, and each region wants to preserve that language and culture, and this is reflected in a variety of local Linux distributions customized into the various local languages.

Alfonso de Cala, of Guadalinex, was the next speaker, leading a brainstorming session aimed at identifying the problems and frustrations of Linux developers throughout Spain. He noted that this diversity of cultures within Spain has led to the creation of numerous derived Linux distributions, with little or no collaboration between developers. Not only are distributions localized for the region, they are also tailored for use by different types of users. This has led to much wasted effort as developers from around the country each tackle the same problems and independently maintain a shared code base. The end result is more fragmentation, when what is needed is more shared code and collaboration.

During Alfonso's presentation we learned that the second version of Guadalinex has been released and that thousands of people use Guadalinex in schools, at home and at work. Guadalinex offers technical and non-technical support. Also Guadalinex shares many of the same problems that are faced by developers around Spain and around the world. Here is a short list of areas, as identified by the audience, in which small distributions, particularly those derived from larger distributions, are having problems.

• Bugs: All software projects have bugs. Many end-users don't know how to send in a bug report or where to send their bug report. Bug tracking is not synchronized with upstream. Users of a stable (old) release want bugs fixed, but developers are more interested in the newest release. If all bugs are reported to one person, that person gets swamped, so there needs to be a better way of determining where bugs should go. Developers want bug reports but they don't need to wade through many reports for the same bug.

• Translations: Translations can be difficult. A user interface might be translated many times, some translations will be better than others, but the best translations may never be incorporated upstream.

• Support and Training: In open source software the components of a distribution come from many sources. Who does the end user go to for support and training?

• Hardware: Many types of hardware are supported, but a small distribution doesn't have access to all hardware. Even a stable Enterprise distribution needs to be able to support new hardware.

• Code Management - Branding and Configuration: Code needs to be customized without breakage. Changes need to be compatible with upstream. Users should be able to tweak the configuration in a way that remains supportable.

• Standardization and Convergence: All distributions need a standard base, a standard user interface, and standard configuration tools. The standard needs to allow for desired diversity. It needs to be easier for people who don't speak English to be involved and contribute to projects.

• Certification: Companies need to run a distribution that is certified for those third party applications (like Oracle) that they need. Localized distributions can not get certified easily.

• Distribution creation tools: Better tools are needed.

• Release schedules: Coordinating distribution release schedules with the schedules of including applications.

Once the problems were identified it was time to talk about how LaunchPad might provide at least some of the solutions. The three LaunchPad applications closest to release are Rosetta, Malone and Soyuz. We should note here that while LaunchPad tools are designed to be used with open source software, they will not themselves be released as open source, at least not initially.

Rosetta: Due for its first release this week, Rosetta may be out by the time you read this. This translation tool provides an easy-to-use web interface for translators, making it easy for a non-technical translator to provide a translation for an application. How does that work? Take any application included in your distribution. The user interface is typically presented in English. To localize the application you could go into the code and change all the strings to the language of choice. Then you'll have to recompile, deal with any introduced errors, and have a version of code that is different from upstream. Worse, the process starts over with each update to the application, even when the application's interface remains the same.

Now imagine that you have translators from all over world who use Rosetta's interface to edit a POTemplate (or POT file) for that application. The application needs only to be aware that POT files exist to present the end user with an interface in their chosen language. New translations can be added and existing translations can be improved without any change to the code. Rosetta keeps track of translations and can export new or improved translations back to the original application. Rosetta can also show you your entire distribution to see what has been translated, and what still needs to be translated.

Right now Rosetta only works with code, changing the face of the application for the non-English speaking user. Later releases of Rosetta will be able to handle man pages, DocBook and OpenOffice documents, and do spell checking. Those interested in using Rosetta may join the mailing list at rosetta-users@lists.ubuntu.com .

Malone: Another piece of LaunchPad is Malone, an extraordinary bug tracking tool. Malone is for developers, not for end users to fill with their bug reports. It will coordinate with other tools such as Bugzilla, tracking bugs both upstream and between distributions. A developer using Malone will be able to see if a bug has been fixed, and where it was fixed so that the fixes can be incorporated into their own distribution. Expect to hear more about Malone in early 2005.

Leading up to a brief look at Soyuz, a central tool in LaunchPad's arsenal, Benjamin "Mako" Hill and Ismael Olea led a discussion on collaboration and convergence. Various barriers to collaboration and convergence were identified, some political, some practical. The more distribution developers can work together the better it gets. When developers can not or will not collaborate then they will duplicate each other's work, sometimes fragmenting the code as application A in distribution Z diverges from the same application in distribution X.

A few of the barriers to collaboration and convergence include government secrecy, lack of communication/language barriers, geography/time zones, different deadlines and priorities, lack of resources, infrastructure, branding, unrealistic requirements, different hardware/architectures, and so on. The idea of LaunchPad is to provide tools that will eliminate as many barriers as possible, so that all Linux distributions can share more and developers can spend less time reinventing the wheel. Soyuz is the package tracker, helping the developer to track the packages in the distribution, upload and build source, track bugs, keep information about the packages and their maintainers and provide a wrapper around the version control system. LaunchPad's version control system is called Bazaar and it's forked from Arch. But that's a story for another article.

This is Rebecca Sobol reporting from Mataró Spain.