Skip to content

Maintainers' corner

Jump to bottom
Reto edited this page Dec 21, 2021 · 41 revisions

Welcome to the maintainers' corner of The Lounge.
This page provides our contributors with a broad overview of how we operate, and our project maintainers with a ground set of rules and recommendations to follow.

  1. Maintainers and responsibilities
  2. Review process
  3. Test a PR locally
  4. IRC channel
    1. Manage privileges
  5. Releasing The Lounge
    1. Releasing Docker images

Maintainers and responsibilities

The primary duty of a project maintainer is to review opened PRs (process detailed below), and assess open issues by providing content and/or approval/refusal to an issue author, assessing duplicates or invalid issues, ...

People listed below are the project maintainers of The Lounge:

People listed below are past or less active maintainers:

Additionally, the following folks are not core maintainers, but help with other projects of the organization:

Review process

Each PR must be reviewed and approved by 2 project maintainers minimum using GitHub reviews ("Review changes" button).

When the change is non-trivial, and in addition to the two reviews, the reviewers should leave extra few days before merging, to make sure other project maintainers can step in if they have concerns.

If the PR comes from a project maintainer and is only made of a minor change, only one review from another reviewer is required. If the change is more involved, the 2-review process applies.

There are a few exceptions that can lead a project maintainer to merge a PR as-is, without any review:

  • A PR opened using the "Revert" button on GitHub, after an earlier PR broke the master branch. No other changes to the original PR may be merged without reviews.
  • When making a release, the commit containing the change log entry, the commit containing the version bump, and the tag for this version bump are made directly to the master branch. See the release section for more details about this.

Project maintainers may also give a 👎 if they have very strong concerns about a PR. Note that a 👎s are a very drastic measure and thus should be used very sparingly and provided with a thorough explanation and details, either on the PR and/or the IRC channel.

Test a PR locally

Assuming you do not have something already running on port 9000, it's as easy as running the following:

./scripts/run-pr.sh <ID> # Replace <ID> with the actual PR ID

Do not forget to switch back to the master branch afterwards.

More details on the GitHub Help and the run-pr.sh script.

IRC channel

The official IRC channel of the project is #thelounge and is registered to us.

Manage privileges

To know who has what privileges on the channel, run:

/msg ChanServ flags #thelounge

Existing project maintainers are given op status (not automatically) and are automatically voiced.

When a new project maintainer joins the organization, ask them to be registered and identified with NickServ, then run:

/msg ChanServ flags #thelounge <nickname> +oV

The counterpart when they leave is simply:

/msg ChanServ flags #thelounge <nickname> -oV

Releasing The Lounge

Before starting, making sure your Yarn is configured like this: TODO: Move this into .yarnrc in the repo

yarn config set version-tag-prefix "v"
yarn config set version-git-message "v%s"
yarn config set version-git-tag true
yarn config set version-sign-git-tag true

  1. Find out what part of the version number to increment (major, minor or patch) by reading the Semantic Versioning document.

  2. In a terminal, make sure you are on master and completely up-to-date with the remote server. To be safe, install dependencies (yarn) and run tests/linting locally (yarn test).

  3. Update the CHANGELOG.md file using the generator: node scripts/changelog (major|minor|patch|vX.Y.Z-(pre|rc).N)

    1. If this is a stable release, you will have to spend a lot of time curating the file before committing it.
    2. If this is a pre-release / RC, simply run the git commit command prompted.

  4. Run yarn version and in the prompt enter the new version. This will bump the version in package.json file, commit, and create a git tag for.

  5. Push both commits and the tag to GitHub: git push --follow-tags Do not use git push --tags.

  6. Go to the release list, click on the new tag, then on "Edit tag", and copy/paste the change log entry to the new release title and description, optionally mark it as a pre-release.

  7. After pushing the tag, Travis CI will build and, if successful, publish it to the npm package. It will also set the correct npm distribution tag.

  8. In #thelounge on Libera.chat, update the version number in channel topic using /cs topic #thelounge <topic>

  9. In the Debian/Ubuntu package repository:

    1. Update the corresponding version field
    2. Create a tag with a name and title matching the full version (e.g. v1.2.3-rc.4).
    3. Travis CI will build and, if successful, upload a .deb file to both releases made in both repositories.

  10. Update the demo by chatting thelounge-bot, demo update in #thelounge

Don't forget to thank the PR authors in a commit comment!

Releasing Docker images

After a release has been cut in the thelounge/thelounge, Docker images are ready to be built in thelounge/thelounge-docker. The release process is composed of both manual and automatic steps which consists of:

  1. Update the version numbers and changelog entry

Versions are hard-coded in the thelounge/thelounge-docker repository in multiple files. The most important places are within the Dockerfiles. There's a handy script (update-version.sh) that does this for you.

If you're releasing a pre-release or a release candidate, make sure to remove the previous pre-release/release candidate entry in CHANGELOG.md. This helps reduce redundant entries.

  1. Open a PR

Commit the changes produced by ./update-version.sh and open a PR. If the PR passes it should be fine to merge. Don't forget to update the CHANGELOG.md file with any relevant changes. See previous changelog entries for reference.

  1. Create a new tag

Create and push a new tag in the same repo (thelounge/thelounge-docker). The tag name is of importance and needs to match the version number of the npm package (for example, 4.3.0-pre.6). Do sign the tag (git tag -s).

When a new tag is created, a GitHub action is triggered which does a cross-platform docker build and pushes the resulting images to Docker Hub. You may follow the build process by going to the actions page.

  1. Create a new release in the GitHub repo

Create a new "GitHub release" by going to the releases page. The contents of the release should be the same as the CHANGELOG.md entry.

Make sure to check "This is a pre-release" checkbox if you're not releasing a stable version.

This wiki may be out of date, view the official documentation on our website

View documentation

Clone this wiki locally