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:

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

  2. El asunto puede usar las mayúsculas del componente o alcance, pero el resto del título debe estar en minúsculas.

  3. La segunda línea debe estar en blanco.

  4. La tercera línea debe ser el comienzo de una descripción más larga del cambio en oraciones completas, si es necesario.

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

  6. 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:

  1. A través de nuestro proceso interno para crear paquetes disponibles en Snap Store o https://dl.jami.net.

  2. 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:

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

Para usar la función de compilación automática y actualización automática, instale también 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 verificar una nueva rama para cada contribución/cambio antes de realizar cualquier cambio en los archivos para que pueda git pull fácilmente cualquier cambio futuro desde el flujo ascendente a su rama local principal:

$ git checkout -b my-example-change

Editar una página

Las páginas están escritas en [Markdown] (https://www.markdownguide.org/). Haga clic en «Ver fuente de la página» en la parte superior de cualquier página para abrir la fuente sin procesar de la página y ver cómo se escribió.

Continúe y realice los cambios en los archivos`. md”.

Revisando su trabajo

Desde la base del repositorio, ejecuta:

$ make clean && make html

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

Advertencia

Esta documentación actualmente no se compila con la última versión de Sphinx. Ver [este problema en GitLab] (https://git.jami.net/savoirfairelinux/jami-docs/-/issues/15) para una solución alternativa y actualizaciones sobre el mismo.

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

$ make clean && make watch

Mantén esto ejecutándose en segundo plano, luego navega a http://127.0.0.1:8000 (not the local .html file).

Ahorrar su trabajo

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

Consulte las pautas de mensajes de confirmación para saber cómo escribir un buen mensaje de confirmación.

Presentación de un cambio

La primera vez que intentes enviar tus cambios, Gerrit se quejará de que no tienes un Id de cambio en tu confirmación y proporcionará un comando scp para instalar el gancho de confirmación. Después de ejecutar el comando, debería poder volver a comprometerse e impulsar su cambio:

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

Modificar su trabajo

Un revisor puede pedirle que realice cambios en su parche antes de fusionarlo. ¡Esto no es un problema! Simplemente realice los cambios ` “git add” y ejecute “git commit amend amend” para modificar el parche.

Nota

El modificador “– amend”, que es necesario para decirle a Git que amend/tweak la confirmación más reciente existente en lugar de realizar una nueva confirmación. Este es el flujo de trabajo para actualizar un cambio propuesto cuando se usa Gerrit.

Añadir una página

Si decide agregar una página completamente nueva a la documentación, también debe agregarla a la directiva “toctree” de ese capítulo.

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

```{toctree}
:maxdepth: 1

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