Guidelines, overview of maintenance process, etc.
“Thou shall GPG-sign.”
While contributors are suggested to use GPG, as a maintainer you are required to use GPG to sign commits & merges.
If you don't have GPG signing set up yet, now is the moment to do it.
Preferably use SSH.
There are quite a few articles about that: https://help.github.com/categories/ssh/
Check whether commits are GPG-signed with
git config --global alias.logs 'log --show-signature'
Yes, there might be a situation where something has to be fixed "right now" on master..
Perhaps a security fix, who knows what future holds. If it's not that
important, you're still better off making a PR. Even when you'll just
fast-forward commits from PR onto the
Reasoning for it is that it's always hard to catch bugs/mistakes that you
create, while someone else who just briefly looked at the changeset possibly
can see a problem
Squash & Merge, etc. buttons on the website! The only allowed way of merging is locally, since otherwise merge will not be signed, and websites can fairly well mess things up.
Commits that are about to be merged don't have to be signed, but the
merge-commit must be signed. To simplify the process, and ensure that
things are done "right", it's preferable to use the
which does that for you automatically.
merge-pr.shscript to merge PRs, e.g.
You don't have to use it, but then you're running into risk of breaking travis build of master & other PRs, since it verifies all commit messages, indlucing merge messages.
Risk, that can be avoided when one doesn't type manually merge message :wink:
PR-needs-changeslabel – after requested changes are done, remove the label.
merge-pr.shscript), request a rebase and tag PR with
up for grabstag should be used whenever no one is currently working on the issue, and you're not going to work on it in foreseeable future (hours, day or two).
I-need-info. Remove tag once needed info has been provided.
duplicate, and issue that it was a duplicate of, tag with higher
Weblate provides an easy way for people to translate qTox. On one hand, it does require a bit more attention & regular checking whether there are new translations, on the other, it lessened problems that were happening with "manual" way of providing translations.
To get translations into qTox:
git remote add weblate https://hosted.weblate.org/git/tox/qtox/
git fetch weblate
git log --no-merges master..weblate/master
Cherry-pick from the oldest commit.
check if there are multiple commits from the same author for the same translation. If there are, cherry-pick them accordingly:
git cherry-pick <commit1> <commit2>
If there were multiple commits, squash them into a single one, leaving only
feat(l10n): … line in the commit message.
Get rid of Weblate's formatting and amend the commit using
For translations that haven't yet been cherry-picked repeat steps 4-6.
Once done with cherry-picking, update all translation files, so that Weblate would get newest strings that changed in qTox:
Once PR with translation gets merged,
Reset Weblate to current
since without reset there would be a git conflict that would prevent Weblate
from getting new strings.
It's a good idea to lock translations on Weblate while they're in merge process, so that no translation effort would be lost when resetting Weblate.
Files to edit when adding a new translation:
Follow steps for adding translations from Weblate up to step 5. Next:
Before committing, clean up translation from Weblate and commit the change:
./tools/update-translation-files.sh translations/$TRANSLATION.ts git commit --amend translations/$TRANSLATION.ts
Commit the changes to other files adding language to qTox.
git tag -s v1.8.0
MAJOR– bump version when there are breaking changes to video, audio, text chats, groupchats, file transfers, and any other basic functionality. For other things,
PATCHare to be bumped.
MINOR– bump version when there are:
PATCH– bump when there have been only fixes added. If changes include something more than just bugfixes, bump
v1.7.1 → v2.0.0
MINORrelease tag should include information that changelog is located in the
For details see CHANGELOG.md
PATCHversion after non-fix changes have landed on
masterbranch, checkout latest
git cherry-pick -xcommits from
masterthat you want
PATCHrelease to include. Once cherry-picking has been done, tag HEAD of the branch.
PATCHtag, include in tag message short summary of what the tag release fixes, and to whom it's interesting (often only some OSes/distributions would find given
./tools/create-tarball.shscript, and upload the tarball to the github release that was created by a Travis OSX release job.
Contribute, review & test pull requests, be active, oh and don't forget to mention that you would want to become a maintainer :P
Aside from contents of
CONTRIBUTING.md you should also know the contents of
Once you're confident about your knowledge and you've been around the project
helping for a while, ask to be added to the
qTox organization on GitHub.