Invio di patch

Questa pagina descrive l'intero processo di invio di una patch all'Android Open Source Project (AOSP), incluso come richiedere una revisione e tenere traccia delle modifiche con Gerrit .

Prerequisiti

Per iniziare, assicurati di aver fatto quanto segue:

risorse

  • Per i dettagli su Repo e Git, vedere la pagina Strumenti di controllo del codice sorgente .
  • Per informazioni sui diversi ruoli all'interno della community Android Open Source, vedere la pagina dei ruoli del progetto .
  • Per informazioni sulla licenza sull'apporto di codice alla piattaforma Android, vedere la pagina Licenze .

Per i contributori

Autenticazione con il server

Se condividi un indirizzo IP con altri utenti, le quote possono essere attivate anche per modelli di utilizzo regolari. Ciò può accadere quando, ad esempio, molti utenti sincronizzano nuovi client dallo stesso indirizzo IP in un breve periodo di tempo. L'accesso autenticato utilizza una quota separata per ogni utente, indipendentemente dall'indirizzo IP. Per informazioni sull'attivazione dell'accesso autenticato, vedere Utilizzo dell'autenticazione .

Avvio di una filiale Repo

Per ogni modifica che intendi apportare, avvia un nuovo ramo all'interno del relativo repository Git:

repo start NAME .

Puoi avviare più rami indipendenti contemporaneamente nello stesso repository. Il ramo NAME è locale per il tuo spazio di lavoro e non è incluso né su Gerrit né nell'albero di origine finale.

Fai il tuo cambiamento

Modifica i file di origine e convalida le modifiche.

Conferma le modifiche al tuo repository locale con questi comandi:

git add -A
git commit -s

Modifica descrizioni

  • Riga 1: Titolo

    Fornire un riepilogo di una riga ( massimo 50 caratteri)

    Questo formato è utilizzato da Git e Gerrit per vari display. È la parte più importante e più densa del tuo messaggio di commit. Considera l'uso di prefissi per descrivere l'area che hai modificato, seguita da una descrizione della modifica che hai apportato in questo commit, come questa che ha ui come prefisso:

    ui: Removes deprecated widget

  • Riga 2: vuoto

    Lascia vuota questa riga, sempre.

  • Riga 3: Corpo

    Scrivi una descrizione più lunga, iniziando da questa riga.

    Questo deve contenere un massimo di 72 caratteri. Descrivi quale problema risolve il cambiamento e come. Sebbene questo sia facoltativo durante l'implementazione di nuove funzionalità, è molto utile per gli altri in seguito se fanno riferimento a questa modifica, in particolare per il debug.

    Includere una breve nota di eventuali supposizioni o informazioni di base che potrebbero essere importanti quando un altro collaboratore lavora su questa funzione.

Un ID di modifica univoco e il tuo nome ed e-mail, forniti durante repo init , vengono aggiunti automaticamente al messaggio di commit.

Ecco un esempio di messaggio di commit:

Line 1, Headline - a short description

Line 3, Body - Add the detailed description of your patch here. Use as many lines
as needed. You can write an overall description, then list specifics.

I6e3c64e7a:Added a new widget.
I60c539a8f:Fixed the spinning image.
Per leggere un blog sulle buone descrizioni di commit (con esempi), vedere Come scrivere un messaggio di commit Git di Chris Beams.

Caricamento su Gerrit

Dopo aver confermato la modifica alla tua cronologia personale, caricala su Gerrit con questo comando:

repo upload

Se hai avviato più rami nello stesso repository, ti viene chiesto di selezionare quali caricare.

Dopo un caricamento riuscito, Repo ti fornisce l'URL di una nuova pagina su Gerrit . Fare clic sul collegamento fornito da Repo per visualizzare la patch sul server di revisione, aggiungere commenti o richiedere revisori specifici per la propria patch.

Richiedere una revisione

Dopo aver caricato le modifiche su Gerrit, la patch deve essere rivista e approvata dai proprietari del codice appropriati. Individua i proprietari del codice nei file OWNERS .

Per trovare i proprietari del codice appropriati e aggiungerli come revisori per la tua modifica, segui questi passaggi.

  1. Selezionare il collegamento SUGGERIMENTI PROPRIETARI nell'interfaccia utente di Gerrit per visualizzare un elenco di proprietari di codice per i file nella patch.

    suggerisci il collegamento ai proprietari in Gerrit
    Figura 1. Suggerisci il collegamento ai proprietari in Gerrit
  2. Aggiungi i proprietari del codice dall'elenco come revisori per la tua patch.

Per determinare lo stato dei file nella patch, controlla le seguenti icone accanto ai file nella patch.

  • (icona segno di spunta): Approvato dal proprietario del codice
  • (icona a forma di croce): non approvato dal proprietario del codice
  • (icona orologio): In attesa di approvazione da parte del proprietario del codice
Figura 2. Esempio di file con icone che mostrano lo stato di approvazione del proprietario del codice

Caricamento di una patch sostitutiva

Supponiamo che un revisore abbia esaminato la tua patch e abbia richiesto una piccola modifica. Puoi modificare il tuo commit all'interno di Git, il che si traduce in una nuova patch su Gerrit che ha lo stesso ID di modifica dell'originale.

git add -A
git commit --amend

Quando carichi la patch modificata, sostituisce l'originale sia su Gerrit che nella cronologia Git locale.

Risoluzione dei conflitti di sincronizzazione

Se vengono inviate altre patch all'albero dei sorgenti che sono in conflitto con il tuo, riposiziona la tua patch sul nuovo HEAD del repository dei sorgenti. Per farlo, esegui questo comando:

repo sync

Il comando repo sync recupera gli aggiornamenti dal server di origine, quindi tenta di ribasare automaticamente il tuo HEAD sul nuovo HEAD remoto.

Se il rebase automatico non riesce, eseguire un rebase manuale.

repo rebase

Un altro strumento per gestire il conflitto di rebase è git mergetool . Quando hai unito correttamente i file in conflitto, esegui questo comando:

git rebase --continue

Dopo aver completato il rebase automatico o manuale, eseguire il repo upload per inviare la patch ribasata.

Dopo che una presentazione è stata approvata

Dopo che un invio ha superato il processo di revisione e verifica, Gerrit unisce automaticamente la modifica nel repository pubblico. Altri utenti possono eseguire la repo sync per estrarre l'aggiornamento nei rispettivi client locali.

Per i progetti a monte

Android fa uso di una serie di altri progetti open source, come il kernel Linux e WebKit, come descritto in Android Software Management . Per la maggior parte dei progetti che risiedono in external/ , apportare le modifiche a monte, quindi informare i manutentori di Android della nuova versione a monte che contiene le modifiche.

Potresti anche caricare patch che fanno sì che venga tracciato un nuovo rilascio upstream. Nota che queste possono essere modifiche difficili da apportare se il progetto è ampiamente utilizzato all'interno di Android, come la maggior parte di quelli più grandi menzionati di seguito, che di solito vengono aggiornati con ogni versione.

Un caso speciale interessante è Bionic. Gran parte del codice proviene da BSD, quindi, a meno che la modifica non riguardi un codice nuovo per Bionic, si prega di apportare una correzione a monte, quindi un pull di un file completamente nuovo dal BSD appropriato.

Kernel Android

Preferisci apportare tutte le modifiche a monte. Per indicazioni generali, segui le Linee guida per il contributo del kernel Android .

ICU4C

Apportare tutte le modifiche al progetto ICU4C su external/icu4c nella Home Page di ICU-TC . Per ulteriori informazioni, vedere Invio di bug ICU e richieste di funzionalità .

LLVM/Clang/Compiler-rt

Apportare tutte le modifiche ai progetti relativi a LLVM ( external/clang , external/compiler-rt , external/llvm ) nella pagina LLVM Compiler Infrastructure .

mksh

Apportare tutte le modifiche al progetto MirBSD Korn Shell su external/mksh inviando un'e miros-mksh mail a miros-mksh sul dominio mirbsd.org (non è richiesta alcuna sottoscrizione per l'invio) o su Launchpad

Apri SSL

Apportare tutte le modifiche al progetto OpenSSL su external/openssl nella pagina OpenSSL .

V8

Invia tutte le modifiche al progetto V8 su external/v8 nella pagina del problema V8 . Vedere Contribuire a V8 per i dettagli.

WebKit

Apportare tutte le modifiche al progetto WebKit su external/webkit nella pagina WebKit . Avvia il processo segnalando un bug di WebKit . Nel bug, usa Android per i campi Piattaforma e Sistema operativo solo se il bug è specifico di Android. È molto più probabile che i bug ricevano l'attenzione dei revisori dopo che è stata aggiunta una correzione proposta e sono stati inclusi i test. Vedere Contribuire il codice a WebKit per i dettagli.

zlib

Apportare tutte le modifiche al progetto zlib su external/zlib nella home page di zlib .