The Maintainers’ Corner

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

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 core GNOME modules. For instance, gnome-2-14 would be an excellent choice for a branch name targeting 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.

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 [module].doap file

  • login to Discourse and subscribe to the announcement tag as well as your module specific tag

  • subscribe to devel-announce-list for release-team and other developer-related announcements
    Note: Discourse is preferred over mailing lists

  • be sure to subscribe to your project(s) in Gitlab to receive notifications

  • 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

Deprecated:

  • subscribe to the mailing-list for the module (if you’re not already subscribed)
    Discourse is preferred over mailing lists.

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)

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

See Git/FAQ

Deprecated things

  • The MAINTAINERS file: please create a [module].doap file instead.

  • The Feature Plans page.

MaintainersCorner (last edited 2022-05-04 16:13:24 by SébastienWilmet)