Contribuir a Jami

Hay muchas maneras de contribuir a Jami, incluyendo reportar errores y problemas, contribuir con código, ayudar a empaquetar y mantener Jami para su distribución GNU/Linux u otro sistema operativo, así como contribuir a estos mismos documentos.

¡Por favor vea abajo para saber cómo empezar a contribuir a Jami!

Informe de errores y problemas

Consulte la guía de Guía para reportes para obtener instrucciones paso a paso sobre cómo informar de errores y problemas que encuentre en Jami.

Código de contribución

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-first-issue

You can contact developers directly by adding a comment on the ticket you want to start with. They will be able to guide you through the process.

At some point, you will need to push a patch on https://review.jami.net. For more information on how to do this, please refer to the developer/working-with-gerrit guide.

Envasado Jami

There is two possible ways to package Jami: + Via our internal process to create packages available on the Snap Store or https://dl.jami.net + Via the packaging process of your favorite GNU/Linux distribution

Nota

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

If you choose the second option, here are some useful notes: + For our official release, we stick to a certain Qt version, because Qt is a big dependency and we need to ensure that Jami works with the version we use. Every slight change in the Qt version can break Jami or bring some small unwanted changes (e.g. 6.2->6.4 broke the video pipeline) + We also fork pjproject due to ICE over TCP that is not planned upstream + libupnp got some patches to be sure that it’s build with the non-blocking API. + FFMpeg got some patches for screen sharing. + You can check how dependencies are built in daemon/contrib/src

For internal packaging, everything is located in extras/packaging/gnu-linux. You can follow previous patches to understand your needs. e.g.: https://review.jami.net/c/jami-client-qt/+/28036

We use 3 channels: + Internal for testing purposes + Nightly/Beta/Edge for public beta + Stable for public releases

We generally use internal when we test new distribution or when we package a new Qt version Then we try to generate a nightly per week and one stable per month (if unit tests are green).

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

Nota

Chromium is a hard part to build. the 3 commons problems we got 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

Nota

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).

Contribución a esta documentación

Las contribuciones a estos documentos son siempre bienvenidas y apreciadas, desde pequeñas correcciones hasta capítulos completamente nuevos.

Esta página recorrerá los pasos para crear una nueva página o enviar una corrección. El proceso de revisión de parches es el mismo que:doc:` para cualquier otro proyecto Jami <how-to-submit-a-patch>`, por lo que no explicaremos cada comando.

Nota

Al contribuir a esta documentación, usted acepta poner sus contribuciones disponibles bajo la versión 1.3 de la Fundación de Software Libre, sin secciones invariables, sin textos de cubierta frontal y sin textos de cubierta posterior.

También se compromete a que es el autor de sus cambios, o que los ha copiado de una obra de dominio público o de una obra publicada bajo una licencia gratuita que sea compatible con el GNU Free Documentation License. NO SUBJETE LA LAVORACIÓN DE DECORRACIÓN DE DECORRACIÓN.

Nota

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/

Dependencias

Necesitará que Git esté instalado y configurado para usar su par de teclas SSH, y una cuenta en el Jami Gerrit, donde enviaría sus parches para revisión. Si necesita ayuda con esto, vea:doc:el principio de nuestra guía de presentación de parches <how-to-submit-a-patch> (TODO).

Si desea ver previamente sus cambios localmente en su navegador web, debe instalar Sphinx, el Lea el tema Docs Sphinx, y el parser Markdown ST.

$ pip install --upgrade sphinx sphinx_rtd_theme myst_parser

Si desea utilizar la función de autoconstrucción y auto-refrese, también instale sphinx-autobuild.

$ pip install --upgrade sphinx-autobuild

Cloning del repositorio

Clona el repositorio y configure las configuraciones de empuje como esto:

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

Es posible que desee consultar una nueva sucursal para cada contribución/cambio antes de hacer cualquier cambio en los archivos, para que pueda fácilmente ``git tirar `` cualquier cambio futuro desde arriba a su sucursal local principal:

$ git checkout -b my-example-change

Editar una página

Las páginas se escriben en marcado o reStructuredText. Puedes hacer clic en «Vea página fuente» en la parte superior de cualquier página para abrir la fuente prima de la página y ver cómo fue escrita.

Sigue adelante y haga sus cambios en los archivos .rst o .md.

Revisando su trabajo

Desde la base del repositorio, ejecuta:

$ make clean && make html

Ahora usted debe poder ver la documentación en su navegador web. La página de inicio está en _build/html/index.html.

Nota

Esta documentación no se compila actualmente con la última versión de sphinx. Consulte “este problema en GitLab <https://git.jami.net/savoirfairelinux/jami-docs/-/issues/15`” _ para una solución alternativa y actualizaciones sobre este problema.

Para crear automáticamente la documentación y actualizar su navegador web cada vez que guarde cambios, ejecuta:

$ make clean && make watch

Mantenga esto en el fondo, luego navegar a http://127.0.0.1:8000 (no el archivo.html local).

Ahorrar su trabajo

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

Su mensaje de compromiso debe ser algo así:

Short summary of your change in present tense

Longer description of your change in complete sentences, if necessary.

Jami GitLab issue numbers (e.g. GitLab: #445), if relevant.

Por ejemplo:

Add new page section to contribute guide

Add a new section explaining how to add a new page to these docs,
including listing it in the `toctree` directive of the containing
section/folder index.

GitLab: #123

Presentación de un cambio

La primera vez que intentas impulsar tus cambios, Gerrit se quejará de que no tienes un Change-ID en tu commit, y proporcionará un comando scp para instalar el gancho de commit.

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

Modificar su trabajo

Un revisor puede pedirle que haga cambios en su parche antes de fusionarlo. Esto no es un problema! Simplemente haga los cambios, git agregar `, y ejecute git compromete -amend` para modificar el parche.

Añadir una página

Si decide añadir una página completamente nueva a la documentación, también debe añadirla a la directiva toctree del capítulo.

Por ejemplo, si agregó una nueva página llamada hosting-jams-on-aws-guide.md al manual de usuario de Jami en la carpeta user, debe agregarla en la directiva toctree de user/index.rst, sin la extensión de archivo:

.. toctree::

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