Cómo enviar parches

En esta página, se describen todos los pasos para enviar un parche al Proyecto de código abierto de Android (AOSP), incluida la revisión y el seguimiento de cambios con Gerrit.

Requisitos previos

Para colaboradores

Cómo realizar la autenticación con el servidor

Antes de subir contenido a Gerrit, debes establecer una contraseña que te identifique con el servidor. Sigue las instrucciones de la página del generador de contraseñas. Solo debes hacer esto una vez. Para obtener más información, consulta Cómo usar la autenticación.

Cómo iniciar una rama del repositorio

Por cada cambio que intentes realizar, debes comenzar una nueva rama dentro del repositorio Git pertinente:

    repo start NAME .
    

Puedes iniciar varias ramas independientes al mismo tiempo en el mismo repositorio. La rama NAME es el directorio local de tu lugar de trabajo y no se incluye en Gerrit ni en el árbol de origen final.

Cómo realizar el cambio

Una vez que hayas modificado los archivos de origen (y los hayas validado), confirma los cambios en tu repositorio local:

    git add -A
    git commit -s
    

Proporciona una descripción detallada del cambio en el mensaje de confirmación. Esa descripción se envía al repositorio público de AOSP, por lo que debes seguir estos lineamientos para escribir descripciones de listas de cambios:

  • Comienza con un resumen de una línea (50 caracteres como máximo) seguido de una línea en blanco. Gerrit y Git usan ese formato para varias pantallas.

  • A partir de la tercera línea, ingresa una descripción más larga, que debe ajustarse a 72 caracteres como máximo. Describe qué problema resuelve el cambio y cómo lo hace. La segunda parte es opcional cuando se implementan nuevas funciones, aunque se recomienda usarla.

  • Incluye una breve nota sobre cualquier suposición o información general que pueda ser importante cuando otro colaborador trabaje en esa función.

El siguiente es un ejemplo de mensaje de confirmación:

Short description on first line

    More detailed description of your patch,
    which is likely to take up multiple lines.
    

Se agregan automáticamente al mensaje de confirmación un ID de cambio único, tu nombre y tu correo electrónico, tal como los proporcionaste durante repo init.

Cómo subir el cambio a Gerrit

Después de confirmar el cambio en tu historial personal, súbelo a Gerrit con el siguiente comando:

    repo upload
    

Si comenzaste varias ramas en el mismo repositorio, se te pedirá que selecciones cuáles quieres subir.

Cuando se haya cargado correctamente, el repositorio te proporcionará la URL de una nueva página en Gerrit. Consulta esa página para ver tu parche en el servidor de revisión, agregar comentarios o solicitar revisores específicos.

Cómo subir un parche de reemplazo

Supongamos que un revisor vio tu parche y solicitó una pequeña modificación. Puedes modificar la confirmación dentro de Git, lo que genera un nuevo parche en Gerrit con el mismo ID de cambio que el original.

    git add -A
    git commit --amend
    

Cuando subas el parche modificado, se reemplazará el original en Gerrit y en tu historial de Git local.

Cómo resolver conflictos de sincronización

Si se envían otros parches al árbol de origen que entran en conflicto con los tuyos, deberás reubicar el parche sobre el nuevo HEAD del repositorio de origen. La manera más fácil de hacer eso es ejecutar lo siguiente:

    repo sync
    

Este comando primero recupera las actualizaciones del servidor de origen y, luego, intenta volver a establecer automáticamente tu HEAD en el nuevo HEAD remoto.

Si no se realiza correctamente el ajuste automático, hazlo de forma manual.

    repo rebase
    

Usar git mergetool puede ayudarte a resolver el conflicto de reubicación. Una vez que hayas combinado correctamente los archivos en conflicto, ejecuta lo siguiente:

    git rebase --continue
    

Después de terminar la reubicación automática o manual, ejecuta repo upload para enviar tu parche reubicado.

Después de la aprobación de un envío

Después de que un envío pasa por los procesos de revisión y verificación, Gerrit combina automáticamente el cambio en el repositorio público. Otros usuarios pueden ejecutar repo sync para implementar la actualización en su cliente local.

Proyectos ascendentes

Android utiliza varios proyectos de código abierto (por ejemplo, el kernel de Linux y WebKit), tal como se describe en la sección Administración de software de Android. Para la mayoría de los proyectos de external/, realiza los cambios en sentido ascendente y, luego, informa a los mantenedores de Android acerca de la nueva versión ascendente que contiene estos cambios. También puede ser útil subir parches que nos lleven hacia una nueva versión ascendente, aunque estos pueden ser cambios difíciles de realizar si el proyecto se usa mucho en Android, como la mayoría de los más grandes que se mencionan a continuación, que solemos actualizar con cada lanzamiento.

Un caso interesante es Bionic. Gran parte del código que existe es de BSD. Por lo tanto, a menos que el cambio sea un código nuevo para Bionic, preferiríamos ver una corrección ascendente y, luego, extraer un archivo nuevo del BSD correspondiente.

ICU4C

Realiza todos los cambios en el proyecto ICU4C en external/icu4c en la página principal de ICU-TC. Para obtener más información, consulta Submitting ICU Bugs and Feature Requests (solo disponible en inglés).

LLVM/Clang/Compiler-rt

Realiza todos los cambios en los proyectos relacionados con LLVM (external/clang, external/compiler-rt, external/llvm) en la página de infraestructura de compiladores de LLVM.

mksh

Realiza todos los cambios en el proyecto MirBSD Korn Shell en external/mksh enviando un correo electrónico a miros-mksh en el dominio mirbsd.org (no se requiere suscripción), o bien a través de Launchpad.

OpenSSL

Realiza todos los cambios en el proyecto OpenSSL en external/openssl en la página de OpenSSL.

V8

Envía todos los cambios del proyecto V8 en external/v8 en la página de problemas de V8. Para obtener más información, consulta Contributing to V8 (solo disponible en inglés).

WebKit

Realiza todos los cambios en el proyecto WebKit en external/webkit en la página de WebKit. Para comenzar el proceso, presenta un error de WebKit. En el error, ingresa Android en los campos Platform y OS solo si el error es específico de Android. Es más probable que un informe de errores reciba la atención de los revisores cuando se le agregue una propuesta de solución y se incluyan pruebas. Para obtener más información, consulta Contributing Code to WebKit (solo disponible en inglés).

zlib

Realiza todos los cambios en el proyecto zlib en external/zlib en la página principal de zlib.