The Maintainers' Corner

This page aims at regrouping all the informations, tips, links, etc. that are useful for maintainers.

Useful links for maintainers

• Release process

  • Current Gnome development schedule (simplified version)

  • GNOME module requirements

  • Proposing new modules

  • Making a release

• Git stuff

  • Git documentation for GNOME

• String stuff

  • Explanation of string freeze

  • GnomeI18nDeveloperTips

  • L10N Guidelines for Developers

• Bugzilla stuff

  • Bugzilla product overview page

  • Getting new projects created, new bugzilla aliases, getting permissions to edit bugs

• Account stuff

  • Requesting git/shell/ftp accounts

Branches

The "master" branch (what you get when you do a simple git clone) is used for development of the unstable branch, with maintenance of the stable branch on a git branch. The stable branch is usually created just before the unstable branch is declared stable, because that is when some people start working on the next unstable development phase.

We try to use the same git branch names for all GNOME modules. For instance, gnome-2-14 would be an excellent choice for a branch name targetting the GNOME 2.14 release, according to these rules:

• Use only lowercase characters in branch names.
• Use hyphens in branch names rather than underscores
• Use the format "gnome-MAJOR-MINOR" for the branch name if your branch is targeted for the GNOME MAJOR.MINOR release. Things such as the module name or the word "branch" are not necessary.

When a stable branch is made for a GNOME release, release-team, gnome-doc-list, and gnome-i18n must be notified. If you use the standard branch name format, this will happen automatically. If you have your @gnome.org email alias set up, you will receive a copy of this notification. Otherwise, please check the archives to ensure a branch notification email was sent. Send a notification email to these manually if no automatic email is sent.

If appropriate, also update the jhbuild moduleset with the appropriate revision. e.g. your module's <branch/> tag for gnome-2-20 would become <branch revision="gnome-2-20"/>.

For historical interest, you can read more about this in the branching GEP.

Example

Here's an example, when branching for 2.14 (inside a clone of the module!):

git branch gnome-2-14 master
git push origin gnome-2-14
git branch -d gnome-2-14
git checkout -b gnome-2-14 origin/gnome-2-14

where origin is the local name for the GNOME Git repository. The last two commands is to ensure that your local branch is properly setup to track the remote branch.

If you forgot branching and want to use an older commit for branching, for example to have the last 3 commits in master not included in your new gnome-2-14 branch, use "HEAD~x" (where x stands for the number of latest commits to exclude from your new branch) instead of "master":

git branch gnome-2-14 HEAD~3
git push origin gnome-2-14

A shorter way to create a new remote branch & track it within a local branch is (using a fully qualified ref spec):

git push origin origin:refs/heads/gnome-2-14
git checkout -b gnome-2-14 origin/gnome-2-14

To delete a faulty remote branch use:

#potentially dangerous!
git push origin :gnome-2-14

If unsure use the --dry-run option for git-push first.

I'm a new maintainer, what should I do?

Here are some things you should do when you're becoming maintainer for a module:

• first, ask the previous maintainer(s) or the co-maintainer(s) what you should do

• add yourself to the MAINTAINERS and [module].doap files

• subscribe to the mailing-list for the module (if you're not already subscribed)

• subscribe to devel-announce-list for release-team and other developer-related announcements

• be sure to watch the e-mail addresses used for your module in bugzilla

  • gnome-panel-maint@gnome.bugs is the e-mail address for the gnome-panel module, for example

• ask other/previous module maintainers to mark you as a developer of the module in bugzilla, if needed (allows you to add/edit components, milestones, version numbers, other developers for the module, etc.)

  • if you can't modify status of bugs (but you already should be able to do so since you probably contributed some patches), ask bugmaster@gnome.org for the permissions

• subscribe to the wiki page of your module, if it exists

• read/update the triage guidelines for your module

• read the various documentations available in the link section, particularly the GNOME module requirements

Creating/importing a new module in GNOME git

To create or import a new module, see Git/NewRepository.

Here's a small list of other important steps to do when creating or importing a new module in git:

• tell the translators about it by sending a mail to gnome-i18n
• update jhbuild modulesets
• make valid [module].doap file (see below)
• if you want one, request a bugzilla product

Is a MAINTAINERS file still needed?

No, please create [module].doap files instead.

What should a [module].doap file look like?

A [module].doap file should look like the following:

Example:

<Project xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xmlns:foaf="http://xmlns.com/foaf/0.1/"
         xmlns:gnome="http://api.gnome.org/doap-extensions#"
         xmlns="http://usefulinc.com/ns/doap#">

  <name xml:lang="en">GNOME Shell</name>
  <shortdesc xml:lang="en">Next generation GNOME desktop shell</shortdesc>
  <description>GNOME Shell provides core user interface functions for the GNOME 3
desktop, like switching to windows and launching applications.
GNOME Shell takes advantage of the capabilities of modern graphics
hardware and introduces innovative user interface concepts to
provide a visually attractive and easy to use experience.

Tarball releases are provided largely for distributions to build
packages. If you are interested in building GNOME Shell from source,
we would recommend building from version control using the build
script described at:

 http://live.gnome.org/GnomeShell

Not only will that give you the very latest version of this rapidly
changing project, it will be much easier than get GNOME Shell and
its dependencies to build from tarballs.</description>
  <homepage rdf:resource="http://live.gnome.org/GnomeShell" />
  <mailing-list rdf:resource="http://mail.gnome.org/mailman/listinfo/gnome-shell-list" />
  <download-page rdf:resource="http://download.gnome.org/sources/gnome-shell/" />
  <bug-database rdf:resource="https://bugzilla.gnome.org/browse.cgi?product=gnome-shell" />

  <category rdf:resource="http://api.gnome.org/doap-extensions#desktop" />

  <maintainer>
    <foaf:Person>
      <foaf:name>William Jon McCann</foaf:name>
      <foaf:mbox rdf:resource="mailto:jmccann@redhat.com" />
      <gnome:userid>mccann</gnome:userid>
    </foaf:Person>
  </maintainer>
  <maintainer>
    <foaf:Person>
      <foaf:name>Owen Taylor</foaf:name>
      <foaf:mbox rdf:resource="mailto:otaylor@redhat.com" />
      <gnome:userid>otaylor</gnome:userid>
    </foaf:Person>
  </maintainer>
</Project>

This file needs to be named according to the name of your module (the above is "tasque.doap"), and located in the top directory in the master (doesn't matter what you do in a branch).

The more detailed your DOAP file is, the more this information can be reused. For instance, the 'ftpadmin' script which installs new tarballs on ftp.gnome.org uses the description and the name field to nicely format announcement emails.

CategoryJhbuild