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 you branch, please remember to let release-team, desktop-devel-list, gnome-doc-list, and gnome-i18n know.(release-team@gnome.org, desktop-devel-list@gnome.org, gnome-doc-list@gnome.org, gnome-i18n@gnome.org). It is especially important that translators and documenters know, so they can concentrate on the stable branches during the run up to the final release, and afterwards when further stable releases will be made. If you've created a branch for stable GNOME release, please, include in your mail a plan for your project for the next release cycle. Note that many people would like to know what will happen in next release.

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.

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">Tasque</name>
  <shortdesc xml:lang="en">Easy quick task management</shortdesc>
  <homepage rdf:resource="http://live.gnome.org/Tasque" />
  <mailing-list rdf:resource="http://mail.gnome.org/mailman/listinfo/tasque-list" />

  <maintainer>
    <foaf:Person>
      <foaf:name>Brian G. Merrell</foaf:name>
      <foaf:mbox rdf:resource="mailto:bgmerrell@gmail.com" />
      <gnome:userid>bgmerrell</gnome:userid>
    </foaf:Person>
  </maintainer>
  <maintainer>
    <foaf:Person>
      <foaf:name>Sandy Armstrong</foaf:name>
      <foaf:mbox rdf:resource="mailto:sanfordarmstrong@gmail.com" />
      <gnome:userid>sharm</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 (TODO: only needed in master, or all active branches?).

CategoryJhbuild