¿Cómo contribuye parches al núcleo de Drupal?

¿Cuál es el proceso adecuado para contribuir parches al núcleo de Drupal?

Digamos que encuentro un error en el núcleo de Drupal, lo soluciono y creo un parche . ¿Cómo lo envío?

Si el error está en Drupal 7, ¿tengo que arreglarlo también en Drupal 8 y enviar dos parches? ¿Esto también se aplica a errores / mejoras en la documentación?

¿Todos los parches también requieren una prueba unitaria?

Si el error está en Drupal 7, ¿tengo que arreglarlo también en Drupal 8 y enviar dos parches?

Si el error está presente en la versión que se está desarrollando (en este caso, Drupal 8) y en la versión anterior (Drupal 7), entonces el error se debe solucionar primero en la versión desarrollada actualmente y luego en las versiones anteriores.

Si el error no está presente en la última versión desarrollada, por ejemplo, porque el error es para una función que se ha eliminado o que ya se ha cambiado, entonces el parche debe proporcionarse para la versión anterior a la desarrollada actualmente.

El flujo de trabajo que se sigue es:

• Primero se crea el parche y se envía para su revisión, para la versión más reciente, incluso si todavía está en desarrollo (como en el caso de Drupal 8)
• Una vez que ese parche se aplica a Drupal, se crea un parche que se aplica a la versión anterior y se envía para su revisión.

Puede crear parches para dos versiones de Drupal al mismo tiempo, pero dado que el parche para la última versión de Drupal podría requerir cambios, es mejor trabajar en el parche para la versión desarrollada actualmente, que trabajar en dos parches diferentes que ambos requieren ser cambiado.

Ver también: Política de backport .

¿Esto también se aplica a errores / mejoras en la documentación?

Si lo hace. También en este caso, si la versión desarrollada actualmente elimina la función / método al que se refiere la documentación, entonces el parche debe proporcionarse para la versión anterior.

¿Todos los parches también requieren una prueba unitaria?

Si el parche es para la documentación, no requiere pruebas. El bot de prueba que se ejecuta en http://qa.drupal.org verifica el código de Drupal después de aplicar el parche; Si el parche introduce errores de sintaxis (por ejemplo, porque el comentario se cierra antes de lo necesario), el bot de prueba informará un error sobre el parche antes de ejecutar las pruebas.

Si el parche es para una nueva característica, entonces se requieren las pruebas.

Si el parche es para corregir un error, entonces las pruebas podrían ser requeridas por los mantenedores, si aún no hay una prueba que verifique una característica específica. La prueba generalmente es necesaria para evitar volver a introducir el mismo error al cambiar en el futuro el mismo código. Si el error es simplemente una variable que se inicializa, pero nunca se usa desde una función / método, entonces es probable que las pruebas no sean necesarias.

Cada página de proyecto en drupal.org tiene una pestaña "Control de versiones" en la parte superior. No solo brinda una excelente descripción general de todas las opciones de repositorio de código para el proyecto específico, sino que todos los ejemplos de comandos de git también están diseñados para el proyecto. Incluso puede cambiarlo interactivamente a una versión específica también.

Para el núcleo de Drupal, encontrará esa página en http://drupal.org/project/drupal/git-instructions

Luego, cuando haya creado su parche, simplemente adjunte el archivo del parche a un problema que explique lo que hace el parche.

Dos cosas importantes para señalar es asegurarse de que el parche termine con ".patch" y establecer el estado en "Necesita revisión". Esto para que el testbot lo note y ejecute automáticamente su prueba.

El nuevo código siempre debe ir acompañado de pruebas .

Tenga en cuenta que esto es posible desactivar por proyectos y algunos lo hacen. Sin embargo, para Drupal core está activado, por lo que se probarán todos los parches.

Puede encontrar más en http://drupal.org/contribute/development .