Category Archives: March 2010
Jim Hodapp takes you on a trip through GNOME Journal memory lane to when GJ was first started back in the fall of 2004, and makes an important announcement.
Back in September of 2004, we released the first GNOME Journal issue. One small team of people wrote articles, added formatting to the articles, checked spelling and grammar, and provided the core website infrastructure to publish the GNOME Journal. We had no idea how far it would grow, or in what direction. Today, GNOME Journal has had 18 issues and has thousands of loyal readers.
The GNOME Journal has had volunteers come and go and provide some fabulous work. It is a testament to voluntary organization that we’ve produced original content about GNOME on a consistent basis. Sure, there were periods when GNOME Journal struggled to keep volunteers motivated through busy stages of their lives. I include myself in that list. The beauty of this being voluntary participation, though, is that people either want to participate, or they do not. If they do, they are motivated by something to add value to an issue. If people are not motivated, then there is no force or pressure to have them give of their time and skills against their wishes. This is a beautiful thing.
You, the reader, might be wondering what all of my reflecting is about. Well, it is a sad day for me to say that I am leaving the leadership role of Editor-in-Chief; my ability to devote the time and energy to bringing the best content to the GNOME Journal is currently not possible. But it is a happy day that I’m passing on that role to Paul Cutler. Paul has been an outstanding volunteer within the GNOME Journal and throughout the rest of the GNOME community in general. Just over a year ago, he stepped up by volunteering to be the GNOME Journal release coordinator. Since then, GNOME Journal issues have been the most consistent, coordinated issues we’ve ever had in the 6 years of existence. We’ve even had issues dedicated to a certain theme, which we had not done prior. Paul is a consistent communicator within the GNOME Journal community on the mailing list and in the IRC chat room. So this day is sad, but it is also a very bright day because new and fresh leadership is coming to the GNOME Journal.
Please help me congratulate Paul on being Editor-in-Chief and give him your full support, ambition and creativity. GNOME Journal is situated better than ever to provide original, creative, and innovative content that will hopefully keep pushing GNOME and its community in the right direction. It’s been a fun ride for me for the last 6 years, but it’s time for me to move on. I will still be in the community and I hope to devote more of my time to diving into contributing code to GNOME. Thanks to all of the loyal GNOME Journal readers for your support and, most importantly, for reading the GNOME Journal.
Stormy Peters interviews Juan José Sánchez Penas, a member of the GNOME Advisory Board, about his experience working at Igalia and with free software technologies.
Juan José Sánchez Penas is a member of the GNOME Foundation Advisory Board where he represents Igalia. He’s the Co-founder and member of Igalia, an European company specialized in the development of innovative technologies around Linux, Freedesktop.org, Webkit and GNOME. During the past 5 years, Igalia has applied its upstream experience to the mobile market, contributing to open platforms like GNOME Mobile, Maemo, Moblin or LiMo, and developing many projects for relevant international companies. At Igalia, Juan José works in tasks related to business development, group coordination and project management. He is also a part time teacher at UDC since 2001, giving courses related to software design and programming.
How did Igalia get started working on GNOME?
We founded Igalia back in 2001, with the main goal of doing innovative free software development. Some of our first clients wanted ad hoc software for managing their business. As some of us had been following with interest what was happening within GNOME, we decided to take some risks and build a solution on top of the GNOME technologies.
Things were very different then. We started using GNOME 1.x and while we were in the middle of the product development, 2.x was released, so we had to make a huge effort to port everything to the new APIs. In 2002 we started attending GUADEC, getting more and more involved in the project, learning a lot, and progressively went from being external consumers of the platform to become active contributors to the core components.
How many people do you have working on GNOME?
We try to grow slowly and organically, and we have high standards to ensure that we keep the company culture, based on workplace democracy and self-management principles, very strong. We are 40 people in the company and leaving aside a small group of people working in web technologies and a very small management team, the rest of the company is working with or inside GNOME, Freedesktop.org, and related technologies.
Why did you pick the areas/projects that you did to work on?
We try hard to combine strategy and sustainability with selecting technological challenges that are attractive to our hackers. For example, we are investing a lot in WebKitGTK+, as we really think that the synergy with web technologies is one of the keys in the future of the desktop and mobile. But we are also doing that cause we have a team of people strongly motivated to take on that challenge with energy and passion.
What is the biggest challenge working with both companies and a free software community?
Sometimes we the small open source consultancy companies can be seen as working right in the middle of two very different worlds: the evil empire of companies wanting to make profit, and the pure and ethically oriented free software community. But at the end there are a lot of shared interests and huge potential for the win-win. The main challenge is to find the people in key roles of big corporations or institutions that really understand how free software works, the dynamics of the community, and the right way to approach a project and have influence (as opposed to control) in its future.
What is the biggest benefit?
In my opinion the biggest benefit is that bringing powerful companies to contribute directly or indirectly to a free software project is a way to make that project advance faster, and therefore become more useful for more people.
How do you find customers?
We are quite active upstream, and quite specialized, so in many cases it is them who find us. It is becoming more and more common that people contact us because they see our contributions to the repository of a project. The best marketing for a company like us is to git push cool improvements or features to our own projects or projects we contribute to. But of course we also go to many commercial conferences and technical forums, where we try to get closer to companies that could be interested in our services.
How do you hire people? Do you look for people already contributing to GNOME? Do you ever hire anyone that doesn’t already work for GNOME?
This has evolved over the 8 years of company history. Nowadays we mostly hire experienced contributors to the free software platforms that we are most interested in, GNOME being a key one. But we also have hired – and still do sometimes- people with a lot of potential to become good hackers.
What would you like to see the GNOME project do differently?
It is a very difficult question, and I don’t have a specific answer to it. The project is very wide and heterogeneous.
The Desktop is in a stable, mature period nowadays, and not a lot of radical innovation is taking place there. Things like the Shell or Zeitgeist are fresh air and hopefully will contribute to a solid and exciting GNOME 3.0. But in the past years most of the innovation has taken place within the platform itself, with new components that are providing the applications with new exciting ways to interact and cooperate with the world, and that are being used also outside the GNOME desktop, and specifically in the mobile world.
What do you see as the GNOME community’s biggest challenge in the next few years? (Or with GNOME 3.0.)
I really think that the biggest challenge is to compete against and at the same time cooperate with the revolution that is taking place in the web, with very powerful new standards and technologies that are starting to become the default choice for software development and deployment. HTML5 is at the center of all that.
There are many other things, obviously, like ensuring that we have the right accessibility support, keeping the good work in the most innovative core technologies, and consolidating things like the GNOME Shell, which as I said can provide the needed fresh air in the way we interact with the desktop.
What excites you about GNOME?
The thing that excites me most is that what I explained as the biggest challenge can also be seen as a very good opportunity: we can create something very powerful taking the very solid GNOME platform as a building block, and WebKitGTK+ as the bridge between the two worlds.
About the Author
Photo of Juan José Sánchez Penas by csaavedra under a CC-NC-SA 2.0 license.
In this article Jono Bacon describes a number of tools for developers who want to write small, focused fun applications for GNOME.
Within the GNOME community, something we have always tried to communicate effectively is that GNOME is not just a rocking desktop, but a rocking development platform too. Hours and hours of work have been poured into a variety of different areas in the platform, and what we have is a compelling software environment for building a range of applications that satisfy a range of use cases and needs.
The platform has been exercised well; applications such as AbiWord, Gnumeric, PiTiVi, Jokosher, GEdit, Gwibber, Inkscape, Cheese, and the core desktop itself all show off just what is possible with GNOME. While these applications are comprehensive and complete, they are serious engineering projects: they are driven by systematic programmers who are often career developers too. While the platform has served the needs of serious systematic programmers well, recently I have been particularly interested in exploring how we can make GNOME (and on a more personal level, my native Ubuntu community) a more compelling place for a different kind of programmer – the Opportunistic Developer.
Opportunistic Developers are people who want to write small, focused, fun little applications that scratch an itch, even if that itch is merely to have fun. Today on the other side of the field, these kinds of developers are having a whale of a time filling the iPhone App Store with scratch-your-itch types of applications: track your exercise, view a specific website, or push a button and get a fart noise. The iPhone platform has lowered the barrier for bridging the gap between creativity and implementation. I am really keen to see more of these kinds of applications on the GNOME desktop, and on a more personal level, making Ubuntu the perfect platform to deliver GNOME technology on which to produce these tools.
In much the same way that Linux/Apache/MySQL/PHP (LAMP) became a popular arrangement of tools for web development, we have been seeing a similar scenario in the Ubuntu world too, in which a set of tools work well together and are often preferred by developers. These are:
- Python – a simple, easy to learn, flexible and efficient high-level language.
- GTK – a simple, comprehensive and powerful graphical toolkit for creating applications.
- GNOME – the desktop environment that ships with Ubuntu, offering many integration facilities.
- GStreamer – a powerful but deliciously simple framework for playing back and creating audio, video and other multimedia content.
- Glade – an application for creating user interfaces quickly and easily, which can then be loaded right into your Python programs.
- DesktopCouch – a framework for saving content in a database that is fast and efficient, hooks neatly into Ubuntu One and is awesome for replication.
With the exception of Python and DesktopCouch, these tools are entirely based on GNOME technology. Many of the applications that we ship in Ubuntu are written using this platform, and this has helped make it simple for others to get involved and contribute patches and bug fixes to those apps. As such, we have been really keen to expose this collection of tools as a definitive platform for building applications for the Ubuntu desktop; it has helped build a common skill-set across our contributors. Of course, there are other languages and tools too, and they are all welcome components in the opportunistic developer vision, but we have found that choosing a set of tools as a platform and exposing it as a common development target has been useful in building awareness of GNOME for opportunistic developers.
To do this, we have also built a few additional tools which I wanted to share with you folks in this article.
Quickly is a tool for generating and working on software projects. It provides a range of features:
- Project generation – with one command, Quickly can generate a GNOME project with a window, menu bar, status bar, widgets, boiler-plate code and more.
- Editing – you can load all your source files with one command.
- Running – running code is also one command.
- Editing your UI – Quickly has a series of .ui files you can edit in Glade with a single command.
- Packaging – with one command you can generate an Ubuntu package.
- Releasing – also with one command, you publish your application to an Ubuntu Personal Package Archive and deliver it to Ubuntu users.
While most GNOME developers know that Quickly makes it easy to generate GNOME projects and package them for Ubuntu, Quickly actually has a template-based system, which means you can write any kind of application in it (this could include KDE applications and packaging for other distributions). What I like about Quickly is that it automates much of the repetition surrounding software development and it ultimately allows you to deploy software to your users. This instantly allows opportunistic developers to feel a sense of success around their projects as they can develop with ease—and deploy to real users with ease too.
I love Python and I love PyGTK and I am passionate about how tools such as Quickly are lowering the bar for opportunistic programmers to scratch their itch. The problem is, much as Python and PyGTK are incredible for writing apps, like any other tool they still need to be learned, and the best way to learn is by downloading, running and playing with code snippets. Traditionally, this has involved finding scattered bits of sample code online and stuffing them into a directory. Not only do we download other people’s sample code, but we often write our own little code snippets as we learn new parts of these tools, and these would be perfect to share with others. Unfortunately, many of us never end up putting them anywhere online.
I wanted to make it easier for opportunistic developers to get their hands on code snippets and examples to learn from. As such, I created the Acire and Python Snippets projects. These projects provide a simple means in which you get access to a freely available regularly updated library of examples, across a range of different areas. The project has two components:
- Python Snippets – this is simply a library of snippets that live in /usr/share/python-snippets with a series of sub-directories holding different types of snippets (e.g., pygtk/, clutter/, and gstreamer/). We have produced a daily PPA for Python Snippets. This means that every day new snippets are delivered right to your desktop.
- Acire – this is a GNOME front end to the library of snippets and named after my wife, Erica. This provides a great way of browsing and using the snippets.
I have deliberately designed the framework so that the data (python-snippets) is separate from the viewer (Acire), as I am keen for us to have a central body of data (python-snippets) but multiple front ends. While Acire exists today, there is a KDE version in the works and even a web front end.
Acire lets you do a number of things:
- Browse snippets by category.
- View the code (all syntax highlighted and reflecting your system Monospace font choice).
- Run snippets.
- Copy code and paste it elsewhere.
- Edit code inline and execute it, so Acire can be a place to play with the snippets themselves.
- Read links to online documentation and manual pages for included Snippets.
With Acire you will always have a growing knowledge base of real code that you can read, run and share, and the community works together to regularly add to and support that knowledge base.
As a little side story, I saw a rather nice comment on a blog entry I wrote about Acire and the Ubuntu Opportunistic Developer week I put together:
Thank you and the entire Canonical team for putting the Opportunistic Developer Week together!
I’ve been stuck doing heavy, back end enterprise Java programming for the past few years. My interest in programming slowly fizzled out.
On a whim, I decided to check out quickly, acire and the learning materials your team put together. PyGTK erased all the bad taste in my mouth from the Swing applications I’ve coded. (-: I haven’t had this much fun programming in a long time! Thanks so much!
The final component which I wanted to share is pretty Ubuntu-specific, so feel free to skip over this section if you are not interested in using Ubuntu as a collaborative development platform.
So, at this point we have all the tools needed to build applications, learn from code examples, and publish packages that will ultimately be visible in the Ubuntu Software Center. The one area that neither Quickly nor Acire has focused too heavily on is how we collaborate together on software. Few Open Source projects have one sole developer, so we really want developers to work well together, in conjunction with translators, documentation writers, bug triagers and more.
While I love Launchpad and Bazaar, their integration in Ubuntu could have been better. As an example, to get code in and out of Launchpad so you can contribute to a project, you use the bzr command and the process typically works like this:
- You download some code from the Launchpad project with bzr.
- You branch the code. This effectively means making a duplicate directory of the code.
- In that duplicate directory you add a feature, fix a bug or make some other kind of improvement.
- You then commit your changes to your local branch. This effectively tells Bazaar of the changes you have made.
- You then upload your branch to Launchpad. This is called pushing a branch.
- The final step is to propose a merge. This is when you offer your branch and its changes to the project maintainer to merge into the main codebase. Launchpad ties together nicely with bzr to handle this process and has a web front end for doing code review.
Now, understanding how all this works and doing it a few times takes a little getting used to, and much of it is learning how to use the different bzr commands and how they hook in with Launchpad. Recently some work has been going into a project called Ground Control, which provides a graphical interface to the whole process by building it into Nautilus. It works a little like this:
- You create a Projects directory in your home directory.
- Click Places->Home Folder and go to the new Projects folder.
- In there you can see an Identify Yourself button to identify yourself with Launchpad. Click the button and you see a form to enter your Launchpad username and password or create a new Launchpad account.
- Once that’s done, you see a a button where you can select a project to work on. Click on it, enter a project name, select it, and it creates a new folder.
- Now go into that folder. There is a button to download the code. Click it.
- You can now hack on your feature and a button will appear to commit your changes.
- Finally, you will then see a button to propose a merge. You enter some text to describe your change, and it is uploaded.
In addition to this general collaborative process, there is also a process built-in for fixing bugs. You can search for a given bug to fix, it will download the code, and when you click the Upload a Fix button it will upload the branch and attach it to the bug report.
No commands. None. What I love about Ground Control is that it is highly contextual; it is built into the file manager and it only ever shows you a button for what you can do at that time. It is simple and quick and Martin Owens has done a wonderful job with it.
With each of these components we are seeing more and more gaps in the integration and ease of the development process getting filled. I am hugely excited about this and I am excited about it bringing more and more people to GNOME as a development platform and it ultimately generating more and more Free Software for us all to use. We still have a long road ahead though and plenty of good work yet to do.
About the Author
Jono Bacon is the Ubuntu Community Manager, author of The Art of Community by O’Reilly, founder of the Community Leadership Summit and contributor to various GNOME projects, including Jokosher.
Shaun McCance writes about Mallard, a new XML syntax for writing user documentation and help.
Mallard: Better Help for Better Software
Mallard is a beautifully simple system for producing topic-oriented help that can be easily extended by third parties. Although developed initially to meet the needs of the GNOME documentation team, its simple syntax and flexible design have made it an attractive solution for other documentation teams.
This article explains why Mallard was developed, what problems it solves, and where it’s heading.
A Short History
In the beginning, there was DocBook. DocBook is the long-standing champion of free software documentation systems, and it shows in the number of projects that use it. DocBook is a very general-purpose XML vocabulary, containing over 400 distinct elements for everything from bibliographies to synopses of classes and methods in object-oriented programming languages.
GNOME has used DocBook for user and developer documentation for as long as GNOME has provided documentation. Whereas most people convert DocBook to HTML or PDF for delivery, GNOME took the unique approach of installing the source DocBook files and viewing them through a specialized help viewer. This has allowed us to maintain a consistent style, and has paved the way for more dynamic presentations.
Over the years, as we tried to do more with our documentation, we began to encounter more and more problems. One of these problems was unique to upstream providers like GNOME: Our downstream distributors were modifying and extending GNOME, and they needed to update our documentation to match. As early as 2004, we began to think of ways we could make our documentation more extensible for our distributors.
We didn’t set out to create a new format. In fact, the earliest ideas involved extending DocBook in various ways to support dynamic content. But to accomplish what we needed, our DocBook wouldn’t really look like DocBook anymore. Plus, DocBook’s verbose and sometimes complex markup wasn’t helping our volunteer community and occasional contributors.
We needed something simpler, and something that allowed our downstream distributors to build on our content to help users. Mallard was born.
Introduction to Mallard
A Mallard document is a collection of pages. Each page stands on its own. This is different from traditional documentation formats, where a document is a linear sequence of chapters and sections. The idea is not new. Encyclopedias have been organized around self-contained topics for centuries. When the idea is applied to documentation, it’s called topic-oriented help. Users can read what they need without reading an entire manual.
Each Mallard page is stored as an XML file. The Mallard vocabulary contains just over 40 elements, culled from first-hand experience with free software documentation.
Here’s an example Mallard page file:
<page xmlns="http://projectmallard.org/1.0/" id="types-ducks"> <title>Types of Ducks</title> <list> <item><p>Mallard</p></item> <item><p>Eurasian Wigeon</p></item> <item><p>Common Teal</p></item> </list> </page>
A typical application help document will contain dozens of pages, each giving specific instructions or explaining a concept. So we can create more pages and link from one page to another. Here’s another page:
<page xmlns="http://projectmallard.org/1.0/" id="ducks"> <title>Ducks</title> <p>For a list of types of ducks, see <link xref="types-ducks"/>.</p> </page>
As in many other documentation languages, the link text is inserted automatically when the page is displayed. We could also add more content to these pages using Mallard’s built-in markup for common design elements like step lists, notes, and code listings.
A topic-oriented format alone makes it somewhat easier for downstream distributors to add content, but they still have to patch the upstream pages to link to their own content. We needed a way to dynamically insert pages into a document by just dropping some extra files into a directory.
The Power of the Duck Side
The big idea behind Mallard is dynamic links. Instead of embedding all links inside paragraphs, we can declare links and other metadata at the top of the page. The second page above could instead be written like this:
<page xmlns="http://projectmallard.org/1.0/" type="guide" id="ducks"> <info> <link type="topic" xref="types-ducks"/> </info> <title>Ducks</title> </page>
This is now a guide page. Guide pages are special types of pages that hold links to other pages and serve as the navigational glue of the document. When this page is displayed, it will be have a link to “Types of Ducks”. What’s more, “Types of Ducks” will have a link back to this page.
Links declared in the info section reciprocate. You don’t need to specify the link on both ends. It works automatically. This example, however, just lets topics know what guides they belong to. To add third-party content effectively, we need to insert links into guide pages.
So we turn it around. Instead of having a guide page link to its topics, we have topics link into their guides. Here’s another topic page:
<page xmlns="http://projectmallard.org/1.0/" id="scientific-names"> <info> <link type="guide" xref="ducks"/> </info> <title>Scientific Names</title> <list> <item><p>Anas platyrhynchos</p></item> <item><p>Anas penelope</p></item> <item><p>Anas crecca</p></item> </list> </page>
Instead of “Ducks” specifying a topic link to “Scientific Names”, we have “Scientific Names” specifying a guide link to “Ducks”. Guide links and topic links are converses. Whenever there is a guide link, there is a topic link going the other direction. So “Scientific Names” will appear on the “Ducks” page exactly as “Types of Ducks” does.
This simple solution allows us to create help with rich navigational structures that make sense to the reader. More importantly, it allows third parties to seamlessly integrate new content in places where users can actually find it. This means downstream distributors can make our help more useful by adding distribution-specific content. This is also a simple way to integrate plugin help for plugin-heavy applications like the GIMP.
The Mallard 1.0 specification is still a draft, and Mallard continues to improve based on community feedback. Large changes are unlikely before 1.0 is declared final in July, but we have already discussed features that could be useful in future versions of Mallard.
One area where Mallard is likely to grow is dynamic link types. In addition to the guide and topic links discussed in this article, Mallard also features seealso and next links. Next links were added in direct response to community feedback to support linear series of pages. As Mallard is used for larger and more complex documents, we are likely to want other types of navigation. We’re also looking at ways to give writers better control over the grouping and presentation of links.
Every new feature, however, will be scrutinized for simplicity. Simplicity is as key to the design of Mallard as dynamic links. It’s what people like about Mallard. This means that we can’t add every piece of markup that might be useful to somebody.
Fortunately, Mallard can be extended. It was designed with modern XML best practices in mind, and it defines very rigidly how to add new markup from external namespaces. It does its best to ensure that extension elements can provide good fallback content.
One interesting idea for an extension came up as a result of discussions within the Ubuntu documentation team. Some people were worried about the lack of control over what packages can add content into a document. A possible solution is to define an extension that requires links to be cryptographically signed.
Other ideas for extensions include dynamic-content glossaries, simple charting functionality, sortable tables and lists, and automated review tracking. As people push Mallard in new directions, new ideas are bound to come up.
To get started with Mallard, read the Ten Minute Tour. After that, read some of the other Mallard tutorials. The draft specification is easy to read, and is full of examples to help you understand how to use each element.
The beauty of free software is that you can always learn from what other people are doing. For real-world examples of Mallard, take a look at the help documents for Empathy, Calculator, Hamster, GBrainy, and Tetravex. Or look at the source for the projectmallard.org web site, which is all written in Mallard.
If you’re interested in Mallard, please join the Mallard mailing list.
About the Author
Shaun McCance has over eight years of experience as a writer, programmer, and community leader. A well-known open source documentation leader, he spearheads the GNOME documentation team and maintains many of the programs that make GNOME documentation work. Shaun runs Syllogist.net, a consulting company specializing in documentation tools and community documentation.
You may have noticed the spiffy new GNOME Bugzilla. Sumana Harihareswara presents the story of how and why it came to be.
GNOME is asking for donations to hire a sysadmin. That’s because GNOME’s technological infrastructure—like source control, bug tracking, web and mail servers—make the rest of GNOME possible. Recently, Canonical found its efforts blocked by deficiencies in GNOME’s infrastructure. Specifically, our bugtracking software was too obsolete for them to programmatically interface with. So Canonical recently spent tens of thousands of USD to upgrade the GNOME Bugzilla instance from 2.20 to 3.4—including porting forward several beloved customizations.
The story started with Launchpad, Canonical’s collaborative development tool and the Ubuntu development hub. Launchpad has included a Remote Bug Watch feature from the start. Launchpad users could use this to associate Launchpad bugs with bugs in several external trackers. As Max Kanat-Alexander of consulting firm Everything Solved explains, “the most popular bug-tracker that Launchpad projects were interfacing without outside of Launchpad itself were Bugzilla installations.”
Canonical’s Christian Robottom Reis had previously worked on Bugzilla upstream, and appreciated it: “I know how cool a tool it is. We know organizations are invested in the tools they’ve chosen; we don’t expect them to come across to Launchpad for our primary benefit. So we’ve put work into making sure Launchpad plugs well into their infrastructure. All the work around bug watches, branch synchronization and translations emphasizes our coexistence with other tools.”
Kanat-Alexander had worked with Bugzilla upstream to add Launchpad integration capabilities to Bugzilla 3.4. As FLOSS projects upgrade to Bugzilla 3.4 and up, this may reduce bug duplication across the entire Linux ecosystem.
But a big part of the equation was missing. “In particular,” Kanat-Alexander continues, “the single most popular bug-tracker for Launchpad projects outside of Launchpad itself was the GNOME Bugzilla.” Since Ubuntu depends heavily on GNOME, Launchpad bugs often related to (or were duplicates of) GNOME bugs. As you can see from the list of remote bug trackers, GNOME has (at the time of writing) 15761 associated watches, as compared to the next highest bugtrackers, Debian at 12231 (followed by KDE, freedesktop.org, SourceForge.net, and Mozilla, all in the thousands).
But the remote watch didn’t work with GNOME’s fairly ancient Bugzilla. As Bugzilla development passed its 3.4 release and worked on 3.6, GNOME’s instance was still on 2.20, originally released in September 2005. And the age was showing. As Kanat-Alexander notes, “There were productivity issues, many needed new features, and serious, serious performance problems. Bugzilla 2.20 was WAY slower than version 3.0 or above, and it was on a old, slow server to boot.” Bugzilla 2.20 had been end-of-lifed in November 2008, so GNOME’s installation was also barred from getting security fixes.
Because of the disconnect, Ubuntu developers were wasting substantial time manually associating Launchpad and GNOME bugs. That bottleneck made Reis unhappy. “It’s hard to measure efficiency financially, but our view of engineering process is that it’s absolutely strategic to us. If engineers are spending time doing chores instead of engineering, we try hard to find tools to assist them,” Reis explains.
Canonical considered asking GNOME sysadmins to install a plugin that older bugtrackers, such as Bugzilla 3.0, can use to integrate better with Launchpad’s remote bug watch. “That plugin offers the same kind of API as Max’s additions to Bugzilla 3.4,” says Canonical engineer Graham Binns. “But the GNOME Bugzilla was, at the time, too out-of-date to be able to work with the plugin.”
GNOME Bugzilla had so many modifications that upgrading it would be arduous. “The GNOME resources available to upgrade Bugzilla to any version after 2.20 were basically nonexistent. Though Olav [Vitters] and the other system administrators had tried for many years to find the time and assistance to port forward the massive GNOME Bugzilla customizations (or even better, contribute them upstream), since everybody was operating on a volunteer basis, the time for such a massive project just couldn’t be found,” says Kanat-Alexander.
Canonical then offered to pay for Everything Solved to port forward key custom features (such as the Bug-Buddy interface, CSS customizations, and browse.cgi) as Bugzilla 3.4 features or extensions, and then upgrade GNOME’s bugtracker. Everything Solved’s initial estimate (for porting all customizations) had proven prohibitively expensive and lengthy for Canonical’s tastes, so Vitters, GNOME sysadmins and developers, and Everything Solved developed a list of key features to keep. They left some low-priority ones out, such as canned responses and the points system. The GNOME Foundation accepted this offer, acknowledging a tradeoff in some functional regressions just after the upgrade. Stormy Peters, GNOME Foundation Executive Director, was especially pleased to see improvements in GNOME infrastructure coming from a company, a consultant, and the GNOME Foundation working together.
Kanat-Alexander and Peters worked out an agreement, and in April 2009, the development work began. Graham Binns updated Launchpad’s bug syncing code to work with the API that Kanat-Alexander was adding to Bugzilla.
In August 2009, Everything Solved delivered the final customizations to GNOME’s volunteer sysadmins. The consultant and sysadmins moved Bugzilla to new servers donated by Red Hat, optimized MySQL performance, tested the new customizations, and then did the final rollout. To minimize downtime, Everything Solved also added upstream fixes to speed up the Bugzilla upgrade process.
GNOME bug-wranglers can now enjoy Bugzilla’s per-product permissions, duplicate prevention, localization, and myriad enhancements from the last few years. And Bugzilla users will get to enjoy several features that started with GNOME’s modifications. The browse.cgi view gives you a dashboard view of a project’s outstanding bugs and patches. Users can indicate the status of an attachment to a bug (e.g., “accepted-commit_now” or “needs-work”). Everything Solved also developed a stack-trace parsing extension, traceparser, for Bugzilla 3.6. All in all, Everything Solved upstreamed more than forty features or bugfixes.
GNOME-related Bugzilla contributions are still necessary, Vitters reminds us: we need to port Bugzilla 3.4 extensions to 3.6, and some customizations still haven’t gotten ported at all. But according to Kanat-Alexander:
“The community (particularly Frédéric Peters) stepped up to develop the most important of the ‘missing’ features that hadn’t been ported forward! Though before the upgrade it was almost impossible to get a review or any code assistance with developing customizations for Bugzilla, after the upgrade, with a ‘finished’ product in place, the contributions really started rolling in.”
Launchpad remote bug watch developers still have a lot of work to do from their end. Canonical is eager to see Mozilla, KDE, and Freedesktop.org upgrade their bugtrackers to improve Launchpad integration. GNOME was Canonical’s highest priority, though; “we haven’t worked officially with any other organization to get this installed,” says Reis, confirming GNOME’s critical importance to Ubuntu.
In short, the makers of Launchpad paid for improvements to Bugzilla, a competing product—not to mention that Ubuntu’s competitors will benefit from improvements to GNOME. As Reis notes, Canonical views this as “bridging the gap” from Ubuntu to upstream.
In the open source community we’re generally skeptical of bug bounties. We worry that paying for development work crowds out volunteer labor instead of adding to it, and degrades intrinsic motivation in favor of extrinsic rewards. And while branded parties and swag feel nice, it’s debatable how much they really contribute to FLOSS. But Canonical, GNOME, and Everything Solved have gone another route, using commercial sponsorship to address longstanding infrastructure rot. Canonical, Google, Collabora, and Nokia recently donated to aid in hiring a fulltime GNOME sysadmin, continuing in (hopefully) corporate/community partnership, not displacement.
About the Author
Sumana Harihareswara manages projects and people. She has worked at Collabora, Fog Creek Software, and Salon.com, and contributed to the AltLaw, Empathy, Miro, and Zeitgeist open source projects. She is currently an editor for GNOME Journal and a blogger at GeekFeminism. She blogs at Cogito, Ergo Sumana and microblogs at Identi.ca.
Will Kahn-Greene introduces the GNOME Miro community, a website that brings GNOME-related videos to users.
Introducing GNOME Miro Community
In November 2009, I released GNOME Miro Community. I’d just had a hard time finding GUADEC 2009 session videos, and Participatory Culture Foundation had just released the Miro Community curated video collection and search platform. So I decided to create a Miro Community focusing on GNOME-related video, so the next person will have an easier time finding things.
Initially, the site contained GUADEC 2009 session videos with titles and descriptions pulled from the GUADEC conference website, plus some other videos I found on YouTube and Vimeo. Since then, I’ve talked with people in the GNOME community and have been growing the site with video from several places. Already the site provides a valuable resource for GNOME-related video. For example, it’s the one place on the web you’ll see links to:
- Gtk+ Kick-Start Tutorial
- Debugging with Accerciser – Basic Debugging of an Application
- GUADEC 2009: Owen Taylor’s Introduction to the Gnome Shell
This article is an introduction to GNOME Miro Community, how to use it, your role in the site, and my hope for its future direction.
What is GNOME Miro Community?
At its heart, GNOME Miro Community is an index of GNOME-related videos regardless of where they exist on the Internet, compiled by an editor, with metadata that makes the videos on the website easier to find.
GNOME Miro Community runs on Miro Community, developed by Participatory Culture Foundation. The software is built with Django and licensed under the AGPL. PCF stewards development of Miro Community, and hosts Miro Communities for non-profit organizations and groups for free.
Why is it useful?
Last year, if you searched Google for “guadec 2009”, you’d have found a few short videos of events that happened at GUADEC, but no video for conference sessions. Doing a Google search for “gcds 2009” finds the GeekSoc index of all the video files, but that’s just a list of filenames and isn’t particularly usable.
If you did a Google video search for screencasts of GNOME Shell, hoping to learn how far along the GNOME Shell developers are and what it looks like these days, you would see 10 pages of search results. Most of these results are short, soundless screencasts that have no narrative, no indication of what version of GNOME Shell is being demonstrated, and little useful metadata. Half of them seem to cover installing GNOME Shell on different GNU/Linux distributions. How do you find what you’re looking for? How can you see what the status of the project is?
If you want to make a series of marketing videos that explain to the GNOME user base what GNOME 3 is really all about, where do you host it so that people will see it? How do you get around the circular problem where you have to post it on SomeVideoHost because that’s where everyone looks for videos because that’s where everyone publishes their videos because…?
GNOME Miro Community seeks to solve these problems by:
- bringing GNOME-related video together in a single index
- making sure the metadata for those videos is valid and useful
- allowing creators/producers to host video wherever
GNOME Miro Community brings GNOME-related videos together into a single website. New videos can be submitted with the “Submit video” link. You can also use GNOME Miro Community to search for GNOME related videos on several video search sites. (More about submitting videos later.)
When users add videos to the site, I go through the metadata for them to make sure it’s valid and useful. Additionally, I make adjustments based on comments on the video which ensures that metadata will improve over time. This improves search tremendously.
GNOME Miro Community allows video to be hosted on sites that meet the creator/publisher’s needs. For example, videos can be on blip.tv, which supports Ogg Theora and doesn’t have a 10-minute maximum duration, or on Vimeo or YouTube, which have more social-type features. They can even live on your own server—wherever meets your needs.
Much of the site’s value comes from it being carefully curated rather than automatically generated. Miro Communities are moderated by a group of curators who approve and reject submissions and discovered video, edit video metadata, work with the community to create new video, and maintain the site’s focus.
Quick site tour
There are a variety of ways to navigate the site and find videos you’re looking for:
Videos on the site fall into zero or more categories. We add categories as we go along when we find a critical mass of videos pertaining to a specific subject. You can view all the videos in a category by clicking on one of the categories on the site.
You can search for videos on GNOME Miro Community using words found in the video’s title, description or tag fields.
Videos that have been recently published and approved onto the site will show up in the New feed.
Curators choose particularly interesting videos to Feature on the site. They’ll show up in the Featured feed and appear on the site’s front page.
You can subscribe to New, Featured, and category RSS feeds with your video podcast client (Banshee, Miro, Rhythmbox, gPodder, etc.). RSS feeds have enclosures with links to video.
On the video page, you can comment on the video, sharing your thoughts, providing updates, and pointing out problems. You’ll also find a link to the video’s origin (such as its YouTube webpage). This makes it easier to follow discussions that might be spread out across different sites.
On most pages is a “Submit video” link, which allows you to submit videos that aren’t yet listed in GNOME Miro Community. When a video is submitted, it goes into the moderator queue to be looked at. It may spend some time there since this is a volunteer-run site. The curators can update the metadata for the submission and approve or reject it.
When you submit a video, make sure it has the following:
- Sound or subtitles that narrate what’s happening in the video. Screencasts that lack a narration are hard to follow unless you already know what’s going on. If the video has sound, make sure the sound is audible and isn’t filled with pops and fizzes.
- Useful name and description. It’s important to have a useful name and description for two reasons. First, it makes it easier for someone to know what the video is about before they watch it. Second, when a user searches for videos, they’re searching for words found in the name and description of the video. For screencasts, lectures, and conference sessions, it helps to have the name of the speaker and venue in the description.
- Useful tags. When a user searches for keywords, it helps if those keywords are in the tags for relevant videos. Additionally, GNOME Miro Community can show you all the videos with a specified tag.
If you submit a video that doesn’t have the above, we’ll do our best to fill in the details.
Conferences, hackfests, local user groups, and classes often produce a bunch of related videos. We’d love it if you’d build an RSS feed with enclosures and tell us the URL. We can add the URL for the feed as a source. When you add new videos to the feed, GNOME Miro Community will discover them and automatically add them to the moderator queue. This saves you time, compared to submitting the videos one at a time.
The future of GNOME Miro Community
An important part of making this happen is you: your participation in GNOME Miro Community makes it richer for everyone.
If you’re involved in video creation, take the time to submit it or send us an email about its existence.
If you find problems with videos that are currently on GNOME Miro Community, add a comment to the video or send us an email about the problem.
If you’re doing the A/V work for a hackfest, local user group, or conference session, send us an email so that we know about it and can help you get the video on the site.
If there are videos on GNOME Miro Community that you think are important, write about them on your blog and tell others—video is a powerful medium for sharing and it’s important to use.
The work we’re doing on GNOME Miro Community will be reflected in the Miro Community software itself and vice-versa. As the underlying software adds features such as better HTML5/video support, subtitles support, better interface, etc., so, too, will GNOME Miro Community. If you’re interested in helping out with Miro Community development, let me know.
I hope that GNOME Miro Community fills an important gap and makes it easier for us to share our thoughts, our work, and our progress, and educate people about what makes GNOME and GNOME technologies great.
Take a spin around the GNOME Miro Community site today!