What’s involved in maintaining a package?

5:06 pm community, freesoftware, gnome, maemo, meego

Reposted from Neary Consulting

An interesting question was asked on a MeeGo mailing list recently: What does it mean to be a maintainer of something? How much time does it take to maintain software? It resulted in a short discussion which went down a few back alleys, and I think has some useful general information for people working with projects like MeeGo, which are part software development, part distribution.

Are you maintaining software, or a package?

The first question is whether you are asking about maintaining something in the Debian sense, or the GNOME sense?

A Debian package maintainer:

  • Tracks upstream development, and ensures new releases of software are packaged and uploaded in a timely manner
  • Work with distribution users and other maintainers to identify bugs and integration issues
  • Ensure bugs and feature requests against upstream software are reported upstream, and bugs fixed upstream are propagated to the distribution packages
  • Fix any packaging related issues, and maintain any distribution-specific patches which have not (yet) been accepted or released upstream

A GNOME project maintainer:

  • Makes regular releases of the software they maintain (typically a .tar.gz with “./configure; make; make install” to build)
  • Are the primary guardians of the roadmap for the module, and sets the priorities for the project
  • Works with packagers, documenters, translators and other contributors to the software to ensure clear communication of release schedules and  priorities
  • Acts as a central point of contact for release planning, bug reports and patch review and integration
  • A typical maintainer is also the primary developer of the software in question, but this is not necessarily the case

Obviously, these two jobs are very different. One places a high priority on coding & communication, another on integration, testing, and communication.

So how much time does maintaining software take?

Well, how long is a piece of string?

To give opposite extremes as examples: Donald Knuth probably spends a median time of 0 hours per week maintaining TeX and Metafont. On the other hand, Linus Torvalds has worked full time maintaining the Linux kernel for at least the past 15 years, and has been increasingly delegating large chunks of maintenance to lieutenants. The maintenance of the Linux kernel is a full time job for perhaps dozens of people.

On a typical piece of GNOME software (let’s take Brasero as an example) much of the work is simplified by following the GNOME release schedule – the schedule codifies string freezes and interface freezes to simplify the co-ordination of translation and documentation. In addition, outside of translation commits, Brasero has had contributions from its maintainer, Philippe Rouquier, and 6 other developers in the last 3 months. Most of these changes are related to the upcoming GTK+ 3 API changes, and involve members of the GTK+ 3 team helping projects migrate.

In total since the 2.32.0 release, there have been 55 commits relating to translations, 50 commits from Philippe, 9 from Luis Medina, co-maintainer of the module, and there were 4 commits by other developers. Of Philippe’s 50 commits, 14 were related to release management or packaging (“Update NEWS file”), 5 were committing patches by other developers that had gone through a review process, and the remainder were features, bug fixes or related to the move to the new GTK+. Of Luis’s commits, 2 were packaging related, and 2 were committing patches by other developers.

This is a lot of detail, but the point I am making is that the “maintenance” part of the work is relatively small, and that the bigger part of maintenance is actually sending out the announcements, paying attention to bug reports and performing timely patch review. I would be interested to know how much time Philippe has spent working on Brasero over the past release cycle. I would guess that he has spent a few hours (somewhere between 5 and 10) a week.

On the other hand, the Debian maintainer for the Brasero package has a different job. There are 6 bugs currently forwarded upstream from the Debian bug tracker, and another 35 or so awaiting some final determination. A number of these look like packaging bugs (“you need version X of dependency Y installed”). The last release packaged and uploaded was 2.30.3-2, dating from November, and there have been 4 releases packaged in the past 8 months, none by the maintainer.

A typical Debian maintainer is a “Debian developer” for several packages. Pedro Fragoso, the Debian maintainer of Brasero, maintains 5 packages. I think it is fair to say that the amount of time a package maintainer spends maintaining an individual package is quite low, unless it is extremely popular. Perhaps a few hours a month.

The package maintainer has little or no say (beyond interacting with the project maintainer and forwarding on bug reports & feature requests) in what happens upstream, or which features have a high priority. His influence comes primarily from the fact that he is representing a larger user base and can indicate which bugs his distro’s users are running into and reporting regularly, or which feature requests are generating a lot of feedback.

What’s in a word?

It’s clear that a package maintainer is not the same thing as a project maintainer. So when Sivan asked on the MeeGo developer list how he could become a maintainer, he clarified later to say that what he was really asking was “How can I affect change in MeeGo?” To do that, you need to write some code that changes a module, or a number of modules, and then you need to get that code into MeeGo.

How that happens, in all its gory details, is the next instalment in this series of at least 2 articles: The Lifecycle of a Patch (or: Working Upstream).

7 Responses

  1. thp Says:

    Nice summary :) For Maemo (and maybe also MeeGo), both the upstream maintainer and the package maintainer could be (and in the case of Maemo often are) the same person/team, but there are exceptions :)

    That’s even more true for packages that are specifically written for that distro (Debian calls these “native” packages) – where upstream is the same as the package, and upstream does releases “directly” as distro packages. I imagine that would be the case for packages written mainly for MeeGo or apps targetting primarily MeeGo.

  2. Federico Mena Quintero Says:

    May I recommend this as material for your “lifecycle of a patch” post. It’s old, and most of that is already (thankfully) fixed, but it’s what happens when companies don’t fully embrace upstream:

    http://mail.gnome.org/archives/desktop-devel-list/2005-July/msg00515.html

  3. Luis Medinas Says:

    Great post this really explains about different maintainer roles. Nice to see Brasero example here ;)

  4. Benjamin Otte Says:

    I’d like to point out that you downplay the role of the packager quite a bit. A good packager acts as the voice of the distribution to the upstream project. This is a communication job more than anything, but it involves helping the upstream project priorizing bugs (“This needs to be fixed NOW, the Fedora bugtracker has 434 duplicates”) and missing features (“5345 people are cc’ed on our should-support-frobnication bug”). There’s also the other way, in that oftentimes related packages will need to be changed when a new version of your package is released, so you need to communicate upstream plans to your fellow packagers.

    This doesn’t make me do more work than you point out for actual “work” – GStreamer is an hour or two for every release usually, and that involves 2 to 4 packages and that happens every month – but you have to keep up on developer discussion on both sides (distro and upstream) to be able to steer things into the right direction to keep things working smoothly. So hanging out in the right IRC channels and reading/skimming mailing lists is quite an essential part of being a good packager. And I have no idea how much work that is.

  5. Donnie Berkholz Says:

    I want to make one point regarding package effort — the workload has a lot more to do with the complexity of the code and build system than the popularity, although the two definitely synergize to some extent.

  6. Tweets that mention Safe as Milk » Blog Archive » What’s involved in maintaining a package? -- Topsy.com Says:

    [...] This post was mentioned on Twitter by Pedro Fragoso, Luis Medinas. Luis Medinas said: Dave Neary explain what's involved in maintaining a package #brasero #gnome example… great to see us http://tinyurl.com/6dwf7f8 [...]

  7. Neary Consulting » The Lifecycle of a Patch Says:

    [...] other patch lifecycle I’d like to mention, because it is so relevant to distributions, was pointed out to me by Federico Mena Quintero yesterday. What happens to a patch that someone makes and submits to a distribution when they find a bug in [...]