Contribuir

Las contribuciones a Jami siempre son bienvenidas y muy apreciadas. Hay muchas formas de contribuir a Jami, que incluyen:

Informe de errores y problemas,
Contribuir con código,
Ayudar a empaquetar y mantener Jami para una distribución GNU/Linux u otro sistema operativo,
Contribuyendo a la documentación de Jami.

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

Informe de errores y problemas

Consulte la [guía de informes de errores] (/user/bug-report-guide. md) para obtener instrucciones paso a paso sobre cómo informar cualquier problema que pueda encontrar con Jami.

Código de contribución

Para comenzar a contribuir a Jami, mire los buenos primeros números en: https://git.jami.net/groups/savoirfairelinux/-/issues/?sort=created_date&state=opened&label_name[]=good first issue .

Contactar directamente con los desarrolladores agregando un comentario en el ticket. Esto permitirá a los desarrolladores guiarlo a través del proceso.

Continuar con un parche para https://review.jami.net será necesario integrar el código en Jami.

Ver también

Para obtener más información sobre cómo insertar un parche, consulte la guía Trabajando con Gerrit.

Pautas de confirmación de mensajes

Al enviar un parche a Jami, siga las siguientes pautas para los mensajes de confirmación:

La primera línea debe incluir el componente o alcance del cambio, seguido de un breve resumen del cambio en el modo imperativo.(e.g., «añadir nueva función», «fijado error», «documentación actualizada»).
El asunto puede usar las mayúsculas del componente o alcance, pero el resto del título debe estar en minúsculas.
La segunda línea debe estar en blanco.
La tercera línea debe ser el comienzo de una descripción más larga del cambio en oraciones completas, si es necesario.
regla 50/72: La primera línea no debe tener más de 50 caracteres (idealmente), y el resto del mensaje debe ajustarse a 72 caracteres por línea. Esto se puede configurar en su editor de texto.
Si el cambio está relacionado con un problema específico en Jami GitLab, incluya el número de problema en el mensaje de confirmación. Por ejemplo: “GitLab: #123`. Si el cambio está relacionado con varios problemas, enumérelos todos. Si el cambio está relacionado con un problema que no forma parte del proyecto, utilice un enlace al problema en su lugar.

Plantilla para un mensaje de confirmación:

<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]

Por ejemplo:

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

Envasado Jami

Hay dos formas posibles de empaquetar Jami:

A través de nuestro proceso interno para crear paquetes disponibles en Snap Store o https://dl.jami.net.
A través del proceso de empaquetado de su distribución GNU/Linux favorita.

Importante

Jami es un proyecto bastante complejo con muchas dependencias. Esta no es una tarea rápida y fácil y requiere mantenimiento.

Nota

Si Jami se empaqueta usando la segunda opción:

Para lanzamientos oficiales, Jami usa ciertas versiones Qt porque Qt es una gran dependencia. Esto es para garantizar que Jami funcione con la versión Qt en uso. Cada pequeño cambio en la versión Qt puede romper Jami o traer algunos pequeños cambios no deseados. Por ejemplo, 6.2 → 6.4 rompió la canalización de vídeo.
Jami usa una bifurcación del [pjproject] (https://github.com/pjsip/pjproject), ya que ICE sobre TCP es un requisito que no está planificado en sentido ascendente.
libupnp recibió algunos parches para garantizar que esté construido con la API sin bloqueo.
FFmpeg tiene algunos parches para compartir pantalla.
Visitar daemon/contrib/src para comprobar cómo se construyen las dependencias.

Para el empaquetado interno, todo se encuentra en “extras/packaging/gnu-linux`. Puede seguir los parches anteriores para comprender sus necesidades. p.ej.,https://review.jami.net/c/jami-client-qt/+/28036.

Jami tiene 3 canales de lanzamiento:

Interno para fines de prueba
Nightly/Beta / Edge para beta pública
Estable para lanzamientos públicos

El canal interno generalmente se usa para probar nuevas distribuciones o cuando se empaqueta una nueva versión de Qt. Luego, se genera un nightly una vez por semana y un stable una vez al mes (si las pruebas unitarias son verdes).

Los paquetes se envían a:

dl.jami.net (2 máquinas, con un rsync cada 15 min)
Repositorio Ubuntu (snapcraft.io/jami)

Para agregar una distribución:

Agregar Dockerfile
Cambiar Makefile
Actualizar script de empaquetado
Dedos cruzados
Probar el paquete en una máquina virtual

Advertencia

Chromium es una parte difícil de construir. Se han encontrado tres problemas comunes:

GCC es demasiado reciente:
- En general, la solución consiste en importar parches de Gerrit de Chromium para solucionar problemas de GCC
Python es demasiado reciente:
- Generalmente, la solución consiste en usar PyEnv para obtener un entorno virtual con la versión correcta de Python
Dependencias que faltan:
- Durante el paso de configuración de Qt, se enumera la lista de componentes construidos y se enumeran las dependencias que faltan. Generalmente instalando un paquete o actualizando nodo.js soluciona el problema
- Tener en cuenta que si Qt se genera sin Chromium, Chromium debe eliminarse del paquete en la caché de las máquinas de compilación para regenerar una nueva (/var/cache/jami)

Para eliminar una distribución:

Si una distribución es EOL O si hay 2 LT más recientes, la distribución se puede eliminar (por ejemplo, Ubuntu 20, 22, 24—eliminar Ubuntu 20) eliminando los archivos y comprobaciones relacionados.

Nota

Los próximos grandes cambios requeridos son:

Utilizar CMake en lugar de autotools para jami-daemon.
Usar [Ubuntu Core 22 (UC22)] (https://ubuntu.com/core/docs/uc22) en lugar de core20 en snap.
Flatpak/AppImage support? Esto puede simplificar el empaquetado personalizado RPM/Debian.
Genere solo un archivo de instalación unificado de Debian y un archivo de instalación unificado de RPM.
Usar Jenkinsfile para generar, si es posible, paquetes GNU/Linux, macOS y Windows al mismo tiempo.

Para obtener información interna (como cómo publicar en las tiendas, consulte. wiki interno).

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 explicará los pasos para crear una nueva página o enviar una corrección. El proceso de revisión de parches es el mismo que para cualquier otro proyecto Jami, por lo que no se explicarán todos los comandos.

Nota

Al contribuir a esta documentación, acepta hacer que sus contribuciones estén disponibles bajo la [fdl] (/fdl.md), la versión 1.3 o cualquier versión posterior publicada por la Free Software Foundation; sin Secciones Invariantes, sin Textos de Portada y sin Textos de Contraportada.

También promete que es el autor de sus cambios, o que los copió de una obra de dominio público o una obra publicada bajo una licencia libre compatible con la [fdl] (/fdl.md). NO ENVÍE TRABAJOS CON DERECHOS DE AUTOR SIN PERMISO.

Ver también

Si quieres ayudar a traducir esta página, puedes unirte al proyecto y comenzar a traducir esta página en https://explore.transifex.com/savoirfairelinux/.

Dependencias

Se requiere que Git esté instalado y configurado para usar su par de claves SSH y una cuenta en el Jami Gerrit, donde enviaría sus parches para su revisión. Si necesita ayuda con esto, consulte el comienzo de nuestra guía de envío de parches (TODO).

Para previsualizar los cambios localmente en un navegador web, es necesario instalar lo siguiente:

$ pip install --upgrade sphinx sphinx_rtd_theme myst_parser

To use the auto-build and the auto-refresh feature, also install 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

You may want to check out a new branch for each contribution/change before you make any change to the files so that you could easily git pull any future changes from upstream into your main local branch:

$ git checkout -b my-example-change

Editar una página

Pages are written in Markdown. Click «View page source» at the top of any page to open the raw source of the page and see how it was written.

Go ahead and make your changes to the .md files.

Revisando su trabajo

Desde la base del repositorio, ejecuta:

$ make clean && make html

You should now be able to view the documentation in your web browser. The homepage is at _build/html/index.html.

Advertencia

This documentation does not currently build with the latest version of Sphinx. Please see this issue on GitLab for a workaround and updates regarding this problem.

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

$ make clean && make watch

Keep this running in the background, then navigate to http://127.0.0.1:8000 (not the local .html file).

Ahorrar su trabajo

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

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

Presentación de un cambio

The first time you try to push your changes, Gerrit will complain that you don’t have a Change-Id in your commit, and provide an scp command to install the commit hook. After running the command, you should be able to recommit and push your change:

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

Modificar su trabajo

A reviewer may ask you to make changes to your patch before merging it. This is no problem! Simply make the changes, git add them, and run git commit --amend to modify the patch.

Nota

The --amend switch, which is required to tell Git to amend/tweak the existing newest commit rather than making a new commit. This is the workflow for updating a proposed change when using Gerrit.

Añadir una página

If you decide to add a whole new page to the documentation, you must also add it to the toctree directive of that chapter.

For instance, if you added a new page called hosting-jams-on-aws-guide.md to the Jami user manual in the user folder, you should add it in the toctree directive of user/index.md, without the file extension:

```{toctree}
:maxdepth: 1

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