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
- Git stuff
- String and I18N/L10N stuff
- Bugzilla stuff
- Account stuff
- Downstream stuff
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.
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 [module].doap file
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
firstname.lastname@example.org is the e-mail address for the gnome-shell 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 email@example.com 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?