Contribution Guidelines for Developers es

Pautas de contribución para desarrolladores

TODO: necesita reescribir

¡Nos gustaría invitarlo a contribuir con los cambios y hacer que Deepin sea aún mejor de lo que es hoy! Estas son las pautas que nos gustaría que siguieras.

Código de pacto

Todos los proyectos de Deepin se adhieren a Contributor Covenant 1.2. Al participar, se espera que mantenga este código. Informe un comportamiento inaceptable a support@linuxdeepin.com.

Obtener código

Alojamos todo el código en Gerrit y los sincronizamos con GitHub como espejos en tiempo real. Puedes clonar proyectos de cualquiera de ellos. Pero como el único sistema de revisión de códigos, preferimos aceptar las solicitudes de extracción en Gerrit en lugar de los espejos. Para obtener más información sobre la solicitud de extracción, consulte el siguiente tutorial.

Configuración para Gerrit

Inicia sesión en Gerrit a través de la cuenta de GitHub.
Acceda a this page para importar información de la cuenta manualmente. Simplemente presione Siguiente y operará el resultado exitoso con una página vacía. Puede repetir la operación más tarde para mantener el mismo con la última información de la cuenta GitHub.
Instalar el comando git-review , por ejemplo bajo Debian sudo apt-get install git-review
Escriba ~/.config/git-review/git-review.conf con el siguiente contenido para hacer que git-review funcione bien para los proyectos que faltan configuración predeterminada [gerrit] defaultremote = origin 　　　　ps: puede usar git review -r origen para especificar la revisión remota para uso temporal.

Presentar una solicitud de extracción

Clonar proyecto objetivo

Por favor clone el proyecto con el protocolo SSH y soporte commit-msg hook de Gerrit, podría obtener el comando completo en la página de descripción del proyecto, aquí hay un ejemplo git clone ssh://<user>@cr.deepin.io:29418/deepin-music && \ scp -p -P 29418 <user>@cr.deepin.io:hooks/commit-msg deepin-music/.git/hooks/

Checkout nueva rama

Verifique una nueva rama local desde la rama ascendente correcta, y mantenga el prefijo del nombre con contrib/ para hacer que el uso sea claro, por ejemplo contrib/network/bug/conn-missed, contrib/display/dev/support-multi-monitors.

Estilo de codificación

Antes del trabajo de hacking, se recomienda encarecidamente leer las especificaciones del código para garantizar el estilo uniforme. Puede leer las especificaciones de C/C++, Golang y Python en páginas wiki (TODO: en proceso). Y para algunos proyectos especiales, leer el archivo HACKING en el directorio raíz obtendrá más información útil.

Además, una forma fácil de evitar el problema del estilo de codificación es ejecutar las herramientas de análisis de código como pylint y golint . Por lo general, ejecutar make check en el directorio de origen hará ese trabajo (TODO: en proceso).

Escribe tu código

La parte más importante, escribir tu código.

Además, complete el conjunto de pruebas si es posible. Y ejecute todo el conjunto de pruebas del componente afectado. Si todas las pruebas están pasando, eso es suficiente para proponer tu contribución.

Mensaje de compromiso

El mensaje de confirmación de git también debe seguir algunas reglas, como limitar la línea de asunto a 50 caracteres y envolver el cuerpo con 72 caracteres, más detalles para ver aquí.

Además, añada URL relacionadas en líneas separadas, por ejemplo, agregue la URL de Bugzilla si se trata de una confirmación de corrección de errores.

Revisión de código

Ahora es el momento de pasar el código a Gerrit y esperar su revisión. Tenga cuidado, debe seleccionar la rama ascendente correcta, como esta git review release/1.0

Si tiene éxito, el comando imprimirá una nueva página de revisión de Gerrit, acceda a ella y agregue revisores. En general, debe agregar propietario (s) del proyecto como revisor (es). Si no está seguro, solo agregue nuestro mantenedor de la comunidad (@derekdai o @fasheng) como revisor.

Fusionar cambios

Después de que se revisó el código, un aprobador puede enviarlo a la sucursal principal mediante la UI de Gerrit. Hay un botón "Enviar" en la página web para el cambio que aparece una vez que se aprueba el cambio (marcado +2).

Y agregaremos el nombre del autor al archivo CONTRIBUYENTES en el mismo proyecto más adelante.

Reglas

Reglas sobre CHANGELOG
1. DEBE haber un archivo CHANGELOG debajo del directorio raíz del proyecto (marcado mediante git ls-tree HEAD | grep -i changelog |head -n1). Se recomienda usar el nombre CHANGELOG.md.
2. Al hacerlo git push --tags, la etiqueta correspondiente debe existir en el archivo de registro de cambios (marcado mediante grep -F -w $tag $changelog_file)