Contribuer à Jami

Les contributions à Jami sont toujours les bienvenues et sont très appréciées. Il existe de nombreuses façons de contribuer à Jami, notamment en signalant les bogues et les problèmes, en contribuant au code, en aidant à empaqueter et à maintenir Jami pour votre distribution GNU/Linux ou tout autre système d’exploitation, ainsi qu’en contribuant à cette documentation elle-même.

Veuillez lire ci-dessous pour commencer à contribuer à Jami !

Signaler les bogues et les problèmes.

Veuillez consulter le Guide de déclaration des bugs pour obtenir des instructions étape par étape sur la manière de signaler les bogues et les problèmes que vous rencontrez dans Jami.

Contribuer au code

If you want to start to contribute to Jami, you can start by looking good first issues at: https://git.jami.net/groups/savoirfairelinux/-/issues/?sort=created_date&state=opened&label_name%5B%5D=good%20first%20issue

Vous pouvez contacter les développeurs directement en ajoutant un commentaire sur le ticket avec lequel vous voulez commencer. Ils seront en mesure de vous guider tout au long du processus.

A un moment donné, vous aurez besoin de pousser un patch sur https://review.jami.net. Pour plus d’informations sur la manière de procéder, veuillez vous référer au guide developer/working-with-gerrit.

Commit message guidelines

When you submit a patch to Jami, please follow these guidelines for your commit messages:

  • The first line should include the component or scope of the change, followed by a short summary of the change in the imperative mood (e.g. « add new function », « fix bug », « update documentation »).

  • The subject can use the capitalization of the component or scope, but the rest of the title should be lowercase.

  • The second line should be blank.

  • The third line should be the beginning of a longer description of the change in complete sentences, if necessary.

  • 50/72 rule: The first line should be no longer than 50 characters (ideally), and the rest of the message should be wrapped at 72 characters per line. This can be configured in your text editor.

  • If the change is related to a specific issue in the Jami GitLab, include the issue number in the commit message. For example: GitLab: #123. If the change is related to multiple issues, list them all. If the change is related to an issue that is not part of the project, use a link to the issue instead.

Template for a commit message:

<Component/Scope>: <short Summary (imperative, max 50 characters)>

<Detailed description (in present tense) of what was changed and why
it was necessary, wrapped at 72 characters per line to maintain
readability. Include any important details that help others understand
the context of the change. Use this space to explain complex changes
or provide background information.>

[GitLab: #<issuenumber>] or [Link to issue]

Par exemple :

ConversationView: add a new function

Adds a new function to the ConversationView class that allows
the user to sort conversations by date. This function is necessary
to improve the user experience and make it easier to find specific
conversations.

GitLab: #123

Faire des paquets Jami

Il y a deux façons d’empaqueter Jami : + Via notre processus interne pour créer des paquets disponibles sur le Snap Store ou https://dl.jami.net + Via le processus d’empaquetage de votre distribution GNU/Linux préférée

Note

Jami is a quite complex project with a lot of dependencies. This isn’t a quick and easy task and ask for some maintenance.

Si vous choisissez la deuxième option, voici quelques notes utiles : + Pour notre version officielle, nous nous en tenons à une certaine version de Qt, car Qt est une dépendance importante et nous devons nous assurer que Jami fonctionne avec la version que nous utilisons. Le moindre changement dans la version de Qt peut casser Jami ou apporter de petits changements indésirables (par exemple, 6.2->6.4 a cassé le pipeline vidéo) + Nous avons également forké le projet pj en raison de l’ICE sur TCP qui n’est pas prévu en amont + libupnp a reçu quelques correctifs pour s’assurer qu’il est construit avec l’API non-bloquante. + FFMpeg a reçu des correctifs pour le partage d’écran. + Vous pouvez vérifier comment les dépendances sont construites dans daemon/contrib/src

Pour l’empaquetage interne, tout est situé dans extras/packaging/gnu-linux. Vous pouvez suivre les correctifs précédents pour comprendre vos besoins, par exemple : https://review.jami.net/c/jami-client-qt/+/28036

Nous utilisons 3 canaux : + Interne pour les tests + Nightly/Beta/Edge pour la version bêta publique + Stable pour les versions publiques

Nous utilisons généralement l’interne lorsque nous testons une nouvelle distribution ou lorsque nous empaquetons une nouvelle version de Qt. Nous essayons alors de générer un nightly par semaine et un stable par mois (si les tests unitaires sont au vert).

Packages are pushed to: + dl.jami.net (2 machines, with a rsync every 15 min) + Ubuntu store (snapcraft.io/jami)

If you want to add a new distribution, you will need to: + Add Dockerfile + Change Makefile + Update packaging script + Cross fingers + Test the package in a VM

Note

Chromium is a hard part to build. Three common problems encountered are:

  • GCC is too recent:

    • Generally the fix consist of importing patches from Chromium’s gerrit to fix GCC issues

  • Python is too recent:

    • Generally the fix consist of using PyEnv to get a virtual environment with the correct Python’s version

  • Missing dependencies:

    • During the configuration step of Qt, the list of built components is listed and the missing dependencies are listed. Generally installing a package or updating node.js fix the issue

    • Note that if Qt is generated without chromium, we must remove the package in the cache of the build machines to regenerate a new one (/var/cache/jami)

If you want to remove a distribution: + If a distribution is EOL OR if there is 2 more recent LTS, we can remove the distribution (e.g. ubuntu 20, 22, 24 - remove ubuntu 20) by removing related files and checks

Note

For the next big changes we want to:

  • Use CMake instead autotools for jami-daemon

  • Use core22 instead core20 in snap

  • Flatpak/AppImage support? This may simplify custom packaging for RPMs/Debs

  • Only generate one deb instead one per distribution. Same for RPMs

  • Use Jenkinsfile to generate package for Linux/Windows/MacOs at the same time if possible

For internal information (such as how to publish to stores, cf internal wiki).

Contribuer à la documentation

Les contributions à ces documents sont toujours les bienvenues et appréciées, qu’il s’agisse de petites corrections ou de nouveaux chapitres entiers.

Cette page vous explique les étapes à suivre pour créer une nouvelle page ou soumettre une correction. Le processus de révision des correctifs est le même que :doc:`pour tout autre projet Jami `<how-to-submit-a-patch>, nous n’expliquerons donc pas chaque commande.

Note

En contribuant à cette documentation, vous acceptez de mettre vos contributions à disposition sous la licence GNU Free Documentation License, version 1.3 ou toute autre version ultérieure publiée par la Free Software Foundation ; sans sections invariantes, sans textes de première de couverture et sans textes de quatrième de couverture.

Vous promettez également que vous êtes l’auteur de vos modifications, ou que vous les avez copiées à partir d’une œuvre du domaine public ou d’une œuvre publiée sous une licence libre compatible avec le GNU Free Documentation License. NE SOUMETTEZ PAS DE TRAVAUX PROTÉGÉS PAR LE DROIT D’AUTEUR SANS AUTORISATION.

Note

If you want to help to translate this page, you can join the project and start translating this page on https://explore.transifex.com/savoirfairelinux/jami/

Dépendances

Vous aurez besoin de Git installé et configuré pour utiliser votre paire de clés SSH, et un compte sur le Jami Gerrit, où vous enverrez vos patchs pour révision. Si vous avez besoin d’aide pour cela, consultez :doc:`le début de notre guide de soumission de patchs<how-to-submit-a-patch> ` (À FAIRE).

Si vous voulez prévisualiser vos modifications localement dans votre navigateur web, vous devez installer Sphinx, le thème Read the Docs Sphinx, et le parseur Markdown MyST.

$ pip install --upgrade sphinx sphinx_rtd_theme myst_parser

Si vous voulez utiliser la fonction de construction automatique et de rafraîchissement automatique, installez également sphinx-autobuild.

$ pip install --upgrade sphinx-autobuild

Cloner le référentiel

Clonez le dépôt et configurez les paramètres de poussée comme ceci :

$ git clone "ssh://USERNAME@review.jami.net:29420/jami-docs.git"
$ cd jami-docs
$ git config remote.origin.push HEAD:refs/for/master

Vous pouvez vouloir vérifier une nouvelle branche pour chaque contribution/changement avant d’effectuer tout changement dans les fichiers, de sorte que vous puissiez facilement git pull tout changement futur depuis l’amont dans votre branche locale principale :

$ git checkout -b my-example-change

Éditer une page

Les pages sont écrites soit en markdown soit en reStructuredText. Vous pouvez cliquer sur « View page source » en haut de n’importe quelle page pour ouvrir la source brute de la page et voir comment elle a été écrite.

Allez-y et faites vos changements dans les fichiers .rst ou .md.

Prévisualisation de votre travail

Depuis la base du référentiel, exécutez :

$ make clean && make html

Vous devriez maintenant être en mesure de visualiser la documentation dans votre navigateur web. La page d’accueil est à _build/html/index.html.

Note

Cette documentation n’est pas compatible avec la dernière version de sphinx. Veuillez consulter cette question sur GitLab pour une solution de contournement et des mises à jour concernant ce problème.

Pour construire automatiquement la documentation et rafraîchir votre navigateur web à chaque fois que vous enregistrez des modifications, exécutez :

$ make clean && make watch

Laissez le système fonctionner en arrière-plan, puis accédez à http://127.0.0.1:8000 (pas le fichier .html local).

Sauvegarder votre travail

$ git add source/file/you/edited.md
$ git commit

Refer to the commit message guidelines for how to write a good commit message.

Soumettre un changement

La première fois que vous essayez de pousser vos changements, Gerrit se plaindra que vous n’avez pas de Change-Id dans votre commit, et fournira une commande scp pour installer le commit hook. Après avoir exécuté la commande, vous devriez être capable de recommencer et de pousser votre changement :

$ git commit --amend --no-edit
$ git push

Modifier votre travail

Un réviseur peut vous demander d’apporter des modifications à votre patch avant de le fusionner. Ce n’est pas un problème ! Faites simplement les changements, git add, et lancez git commit --amend pour modifier le patch. Notez le commutateur --amend, qui est nécessaire pour dire à git de amender/tweak le dernier commit existant plutôt que de faire un nouveau commit. C’est le flux de travail pour mettre à jour une proposition de changement quand on utilise Gerrit.

Ajouter une page

Si vous décidez d’ajouter une toute nouvelle page à la documentation, vous devez également l’ajouter à la directive toctree de ce chapitre.

Par exemple, si vous avez ajouté une nouvelle page appelée hosting-jams-on-aws-guide.md au manuel de l’utilisateur de Jami dans le dossier user, vous devez l’ajouter dans la directive toctree de user/index.rst, sans l’extension du fichier :

.. toctree::

   ...
   bug-report-guide
   hosting-jams-on-aws-guide