patch 게시 이후의 후속 처리

게시가 끝이 아니라 다음 단계인 이유

Engineering 능력과 앞의 지침을 바탕으로 완벽해 보이는 patch series를 게시했더라도 작업이 끝났다고 생각해서는 안 된다. 경험 많은 kernel developer도 이 실수를 한다. Patch 게시 시점은 다음 단계로 넘어가는 지점이며 이후에도 상당한 작업이 남을 수 있다.

첫 게시에서 더 고칠 것이 전혀 없는 patch는 드물다. Kernel 개발 절차는 게시된 code를 개선하는 데 크게 의존한다. Author는 community와 협력해 code를 kernel 품질 기준에 맞춰야 하며 이 과정에 참여하지 않으면 mainline 포함이 어려워진다.

완성도 높아 보이는 patch series를 게시한 순간은 작업 종료가 아니라 review와 통합 단계의 시작입니다. 첫 version에서 개선할 점이 전혀 없는 patch는 드물며 author는 community와 함께 kernel 품질 기준을 충족할 때까지 책임 있게 수정해야 합니다.

Review 과정에 참여하지 않거나 질문에 답하지 않으면 기술적으로 유용한 변경이라도 mainline에 포함되지 못할 수 있습니다. 게시 이후 대응 시간을 개발 일정에 처음부터 포함하는 것이 중요합니다.

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`
:Translator: Alessia Mantegazza <[email protected]>

.. _it_development_followthrough:

=============
Completamento
=============

A questo punto, avete seguito le linee guida fino a questo punto e, con
l'aggiunta delle vostre capacità ingegneristiche, avete pubblicato una serie
perfetta di patch.  Uno dei più grandi errori che possono essere commessi
persino da sviluppatori kernel esperti è quello di concludere che il
lavoro sia ormai finito.  In verità, la pubblicazione delle patch
simboleggia una transizione alla fase successiva del processo, con,
probabilmente, ancora un po' di lavoro da fare.

È raro che una modifica sia così bella alla sua prima pubblicazione che non
ci sia alcuno spazio di miglioramento.  Il programma di sviluppo del kernel
riconosce questo fatto e quindi, è fortemente orientato al miglioramento
del codice pubblicato.  Voi, in qualità di autori del codice, dovrete
lavorare con la comunità del kernel per assicurare che il vostro codice
mantenga gli standard qualitativi richiesti.  Un fallimento in questo
processo è quasi come impedire l'inclusione delle vostre patch nel
ramo principale.

reviewer와 생산적으로 협업하기

의미 있는 patch에는 여러 developer의 review comment가 달린다. Reviewer가 patch의 가치와 작성 이유를 이해하더라도 5년 또는 10년 뒤 이 code를 포함한 kernel을 유지보수하는 일이 어떨지를 묻는다.

Coding style 수정부터 큰 rewrite까지 많은 요구는 Linux가 10년 뒤에도 계속 개발될 것이라는 전제에서 나온다.

Code review는 어렵고 보상받기 힘든 작업이다. 같은 실수를 반복해서 보면 reviewer가 날카롭게 반응할 수 있다. Review가 화나거나 모욕적으로 느껴져도 같은 방식으로 응답하지 않는다. Review 대상은 사람보다 code다.

Reviewer가 자기 고용주의 목표를 위해 경쟁사를 방해한다고 가정해서도 안 된다. Kernel developer는 고용주가 바뀔 수 있음을 알고 있으며 거의 예외 없이 가능한 한 좋은 kernel을 만들려는 목적을 갖는다.

사소해 보이는 coding style 변경이나 code를 공통 kernel 부분으로 분리하라는 요청에도 대비한다. Maintainer는 code의 일관성을 지켜야 하고 driver 안의 영리한 workaround가 다음 사용 사례를 위한 일반 kernel feature가 되어야 할 수도 있다.

Comment의 표현 방식이나 자존심 때문에 기술적 내용을 놓치지 않는다. Reviewer가 말하려는 바를 이해하고 가능한 항목은 고치며, review에 감사하고 질문에 어떻게 대응할지 답한다.

모든 제안에 동의할 필요는 없다. Reviewer가 code를 오해했다면 실제 동작을 설명하고, 제안에 기술적 반대가 있다면 이유와 자신의 해결책을 정당화한다.

설명이 설득력 있으면 reviewer도 받아들인다. 반대로 다른 사람까지 reviewer 의견에 동의한다면 자신의 해결책 때문에 근본 문제나 해결 대상 자체를 잘못 보고 있지 않은지 다시 생각한다.

Andrew Morton은 code 변경으로 이어지지 않은 review comment마다 code comment를 하나 추가하라고 제안했다. 그러면 미래 reviewer가 같은 질문을 반복하지 않게 할 수 있다.

Review comment가 사라지기를 바라며 무시하는 것은 치명적인 실수다. 이전 comment에 답하지 않은 채 code를 다시 게시하면 patch는 진행되지 않을 가능성이 높다.

Reviewer는 이전 version의 세부 내용을 모두 기억하지 않는다. Repost할 때 이전에 제기된 문제와 해결 방법을 patch changelog에 정리한다. Reviewer가 mailing list archive를 직접 뒤지지 않게 하면 새 version을 더 효율적으로 검토할 수 있다.

대부분의 기술적 이견은 토론으로 해결되지만 누군가 결정을 내려야 할 때도 있다. 결정이 부당하다고 진지하게 판단한다면 더 높은 조정을 요청할 수 있다.

문서 작성 당시에는 Andrew Morton이 community의 존중을 바탕으로 막힌 상황을 자주 풀 수 있는 조정자였다. 하지만 다른 선택을 모두 시도하기 전에 가볍게 escalation해서는 안 되고 조정자가 자신의 의견에 동의하지 않을 가능성도 받아들여야 한다.

Reviewer는 지금 동작하는지만 보지 않고 5년 또는 10년 뒤에도 유지보수 가능한지를 평가합니다. 따라서 style 수정, 큰 rewrite, driver 전용 workaround를 공통 kernel 기능으로 일반화하라는 요청도 장기 유지보수 관점에서 이해해야 합니다.

표현이 거칠게 느껴져도 기술적 관찰을 분리해 읽고, 받아들인 항목과 받아들이지 않은 항목 모두에 근거를 답합니다. 동의하지 않을 때는 실제 동작과 대안을 설명하고 여러 reviewer가 같은 문제를 지적하면 자신의 문제 정의와 해법을 다시 검토합니다.

Review comment를 무시한 재게시에는 진전이 없습니다. 새 revision에는 이전 지적과 해결 방법을 changelog로 정리해 reviewer가 archive를 다시 찾지 않게 하며, 토론으로 풀리지 않는 교착은 다른 경로를 모두 시도한 뒤 신중하게 조정을 요청합니다.

Lavorare con i revisori
=======================

Una patch che abbia una certa rilevanza avrà ricevuto numerosi commenti
da parte di altri sviluppatori dato che avranno revisionato il codice.
Lavorare con i revisori può rivelarsi, per molti sviluppatori, la parte
più intimidatoria del processo di sviluppo del kernel.  La vita può esservi
resa molto più facile se tenete presente alcuni dettagli:

 - Se avete descritto la vostra modifica correttamente, i revisori ne
   comprenderanno il valore e il perché vi siete presi il disturbo di
   scriverla.  Ma tale valore non li tratterrà dal porvi una domanda
   fondamentale: come verrà mantenuto questo codice nel kernel nei prossimi
   cinque o dieci anni?  Molti dei cambiamenti che potrebbero esservi
   richiesti - da piccoli problemi di stile a sostanziali ristesure -
   vengono dalla consapevolezza che Linux resterà in circolazione e in
   continuo sviluppo ancora per diverse decadi.

 - La revisione del codice è un duro lavoro, ed è un mestiere poco
   riconosciuto; le persone ricordano chi ha scritto il codice, ma meno
   fama è attribuita a chi lo ha revisionato.  Quindi i revisori potrebbero
   divenire burberi, specialmente quando vendono i medesimi errori venire
   fatti ancora e ancora.  Se ricevete una revisione che vi sembra abbia
   un tono arrabbiato, insultante o addirittura offensivo, resistente alla
   tentazione di rispondere a tono.  La revisione riguarda il codice e non
   la persona, e i revisori non vi stanno attaccando personalmente.

 - Similarmente, i revisori del codice non stanno cercando di promuovere
   i loro interessi a vostre spese.  Gli sviluppatori del kernel spesso si
   aspettano di lavorare sul kernel per anni, ma sanno che il loro datore
   di lavoro può cambiare.  Davvero, senza praticamente eccezioni, loro
   stanno lavorando per la creazione del miglior kernel possibile; non
   stanno cercando di creare un disagio ad aziende concorrenti.

  - Preparatevi a richieste apparentemente sciocche di modifiche allo stile di
    codifica e a richieste di trasferire parte del vostro codice in parti
    condivise del kernel. Uno dei compiti dei manutentori è quello di mantenere
    lo aspetto del codice. A volte questo significa che l'ingegnoso stratagemma
    nel vostro driver per aggirare un problema deve diventare una caratteristica
    generalizzata del kernel pronta per essere riutilizzata.

Quello che si sta cercando di dire è che, quando i revisori vi inviano degli
appunti dovete fare attenzione alle osservazioni tecniche che vi stanno
facendo.  Non lasciate che il loro modo di esprimersi o il vostro orgoglio
impediscano che ciò accada.  Quando avete dei suggerimenti sulla revisione,
prendetevi il tempo per comprendere cosa il revisore stia cercando di
comunicarvi.  Se possibile, sistemate le cose che il revisore vi chiede di
modificare.  E rispondete al revisore ringraziandolo e spiegando come
intendete fare.

Notate che non dovete per forza essere d'accordo con ogni singola modifica
suggerita dai revisori.  Se credete che il revisore non abbia compreso
il vostro codice, spiegateglielo.  Se avete un'obiezione tecnica da fargli
su di una modifica suggerita, spiegatela inserendo anche la vostra soluzione
al problema.  Se la vostra spiegazione ha senso, il revisore la accetterà.
Tuttavia, la vostra motivazione potrebbe non essere del tutto persuasiva,
specialmente se altri iniziano ad essere d'accordo con il revisore.
Prendetevi quindi un po' di tempo per pensare ancora alla cosa. Può risultare
facile essere accecati dalla propria soluzione al punto che non realizzate che
c'è qualcosa di fondamentalmente sbagliato o, magari, non state nemmeno
risolvendo il problema giusto.

Andrew Morton suggerisce che ogni suggerimento di revisione che non è
presente nella modifica del codice dovrebbe essere inserito in un commento
aggiuntivo; ciò può essere d'aiuto ai futuri revisori nell'evitare domande
che sorgono al primo sguardo.

Un errore fatale è quello di ignorare i commenti di revisione nella speranza
che se ne andranno.  Non andranno via.  Se pubblicherete nuovamente il
codice senza aver risposto ai commenti ricevuti, probabilmente le vostre
modifiche non andranno da nessuna parte.

Parlando di ripubblicazione del codice: per favore tenete a mente che i
revisori non ricorderanno tutti i dettagli del codice che avete pubblicato
l'ultima volta. Quindi è sempre una buona idea quella di ricordare ai
revisori le questioni sollevate precedetemene e come le avete risolte.
I revisori non dovrebbero star lì a cercare all'interno degli archivi per
famigliarizzare con ciò che è stato detto l'ultima volta; se li aiutate
in questo senso, saranno di umore migliore quando riguarderanno il vostro
codice.

Se invece avete cercato di far tutto correttamente ma le cose continuano
a non andar bene?  Molti disaccordi di natura tecnica possono essere risolti
attraverso la discussione, ma ci sono volte dove qualcuno deve prendere
una decisione.  Se credete veramente che tale decisione andrà contro di voi
ingiustamente, potete sempre tentare di rivolgervi a qualcuno più
in alto di voi.  Per cose di questo genere la persona con più potere è
Andrew Morton.  Andrew è una figura molto rispettata all'interno della
comunità di sviluppo del kernel; lui può spesso sbrogliare situazioni che
sembrano irrimediabilmente bloccate.  Rivolgersi ad Andrew non deve essere
fatto alla leggera, e non deve essere fatto prima di aver esplorato tutte
le altre alternative.  E tenete a mente, ovviamente, che nemmeno lui
potrebbe non essere d'accordo con voi.

subsystem tree에 들어간 뒤

Patch가 kernel에 유용하고 주요 review issue가 해결되면 보통 subsystem maintainer tree에 들어간다. Subsystem마다 방식이 다르고 다음 merge window용 tree와 장기 작업용 tree를 따로 둘 수 있다.

Memory management처럼 명확한 subsystem tree가 없는 영역이나 여러 subsystem에 걸친 patch는 -mm tree를 거칠 수 있다.

Subsystem tree에 들어가면 해당 tree를 쓰는 developer가 patch를 기본으로 받게 되고 대개 linux-next에도 포함되어 community 전체에 노출된다. 새로운 reviewer의 comment가 추가될 수 있으며 이전 round와 같은 방식으로 답해야 한다.

주요 review 지적이 해결되면 patch는 보통 subsystem maintainer tree로 들어갑니다. Maintainer에 따라 다음 merge window용 tree와 장기 개발 tree가 분리될 수 있고, 명확한 subsystem이 없거나 여러 영역에 걸친 변경은 `-mm` tree를 거칠 수 있습니다.

Tree에 포함되었다고 review가 끝난 것은 아닙니다. `linux-next`를 통해 더 넓은 개발자 집단에 노출되면서 새로운 comment가 도착할 수 있으므로 앞선 review round와 같은 수준으로 응답합니다.

Cosa accade poi
===============

Se la modifica è ritenuta un elemento valido da essere aggiunta al kernel,
e una volta che la maggior parte degli appunti dei revisori sono stati
sistemati, il passo successivo solitamente è quello di entrare in un
sottosistema gestito da un manutentore.  Come ciò avviene dipende dal
sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.
In particolare, ci potrebbero essere diversi sorgenti - uno, magari, dedicato
alle modifiche pianificate per la finestra di fusione successiva, e un altro
per il lavoro di lungo periodo.

Per le modifiche proposte in aree per le quali non esiste un sottosistema
preciso (modifiche di gestione della memoria, per esempio), i sorgenti di
ripiego finiscono per essere -mm.  Ed anche le modifiche che riguardano
più sottosistemi possono finire in quest'ultimo.

linux-next 충돌과 mainline 통합

다른 developer의 작업과 conflict가 드러날 수 있다. 심한 경우 일부 patch를 미뤄 나머지를 먼저 정리하고 merge해야 한다. 다른 경우에는 관련 developer와 협력하고 patch를 tree 사이에서 옮겨 모두 cleanly apply되게 한다.

linux-next 이전에는 이런 conflict가 merge window에서야 발견되어 급히 고쳐야 했다. 이제는 merge window가 열리기 전에 여유 있게 해결할 수 있다.

Patch가 mainline에 merge되면 축하할 일이지만 작업은 끝나지 않는다. MAINTAINERS file에 자신을 추가한 뒤에도 mainline 포함으로 생기는 새 책임이 있다.

더 많은 developer가 patch를 처음 보고 새로운 comment를 보낼 수 있다. 이미 merge되었다고 무시하지 말고 질문과 제안에 계속 응답한다.

더 중요한 변화는 훨씬 큰 tester 집단이 code를 사용한다는 점이다. 아직 널리 판매되지 않은 hardware driver도 예상보다 많은 사람이 kernel에 build하며 그에 따라 bug report가 생긴다.

다른 tree의 변경과 충돌하면 관련 개발자와 patch 순서, 대상 tree와 dependency를 조정해 전체 series가 clean하게 적용되도록 합니다. 심한 충돌에서는 일부 작업을 미루는 판단도 필요하지만 `linux-next` 덕분에 merge window 전에 문제를 발견하고 해결할 수 있습니다.

Mainline merge는 중요한 이정표지만 유지보수 책임의 시작이기도 합니다. `MAINTAINERS`에 자신을 추가한 뒤 새 reviewer의 질문과 제안에 계속 응답하고, 더 큰 tester 집단에서 들어오는 report를 추적해야 합니다.

L'inclusione nei sorgenti di un sottosistema può comportare per una patch,
un alto livello di visibilità.  Ora altri sviluppatori che stanno lavorando
in quei medesimi sorgenti avranno le vostre modifiche.  I sottosistemi
solitamente riforniscono anche Linux-next, rendendo i propri contenuti
visibili all'intera comunità di sviluppo.  A questo punto, ci sono buone
possibilità per voi di ricevere ulteriori commenti da un nuovo gruppo di
revisori; anche a questi commenti dovrete rispondere come avete già fatto per
gli altri.

Ciò che potrebbe accadere a questo punto, in base alla natura della vostra
modifica, riguarda eventuali conflitti con il lavoro svolto da altri.
Nella peggiore delle situazioni, i conflitti più pesanti tra modifiche possono
concludersi con la messa a lato di alcuni dei lavori svolti cosicché le
modifiche restanti possano funzionare ed essere integrate.  Altre volte, la
risoluzione dei conflitti richiederà del lavoro con altri sviluppatori e,
possibilmente, lo spostamento di alcune patch da dei sorgenti a degli altri
in modo da assicurare che tutto sia applicato in modo pulito.  Questo lavoro
può rivelarsi una spina nel fianco, ma consideratevi fortunati: prima
dell'avvento dei sorgenti linux-next, questi conflitti spesso emergevano solo
durante l'apertura della finestra di integrazione e dovevano essere smaltiti
in fretta.  Ora essi possono essere risolti comodamente, prima dell'apertura
della finestra.

Un giorno, se tutto va bene, vi collegherete e vedrete che la vostra patch
è stata inserita nel ramo principale de kernel. Congratulazioni!  Terminati
i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file
MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il
lavoro non è ancora finito.  L'inserimento nel ramo principale porta con se
nuove sfide.

regression 수정과 장기 유지보수

가장 심각한 report는 regression이다. 자신의 patch가 regression을 만들면 가능한 한 빨리 수정해야 한다. Author가 수정하지 못하고 다른 사람도 고치지 않으면 stabilization period 중 patch가 거의 확실히 제거된다.

Regression을 고치지 않아 patch가 제거되면 mainline에 넣기 위해 들인 작업이 무효가 되고 앞으로 다른 작업을 merge하기도 어려워질 수 있다.

Regression 뒤에는 일반 bug를 고친다. Stabilization period는 mainline release에 code가 처음 등장하기 전에 품질을 높일 가장 좋은 시기다. 기존 문제를 처리한 뒤 새 feature patch를 시작한다.

다음 stable release나 주요 distribution이 해당 kernel version을 채택하는 시점에도 새 bug report가 생길 수 있다. 자신의 작업에 대한 기본적인 책임으로 계속 대응한다.

Community는 merge 뒤 code에 관심을 잃는 developer를 기억한다. 다음 patch를 평가할 때도 author가 향후 유지보수하지 않을 것이라는 가정을 하게 된다.

가장 긴급한 report는 기존 동작을 깨뜨린 regression입니다. 가능한 한 빨리 원인을 확인하고 fix를 보내야 하며 해결되지 않으면 stabilization 기간에 변경 전체가 제거될 수 있습니다.

Regression 뒤에는 일반 bug도 처리해 첫 mainline release의 품질을 높입니다. 다음 stable release나 주요 distribution 채택 시점에도 report가 늘 수 있으므로 merge 이후에도 계속 대응해야 하며, 이런 이력은 다음 patch에 대한 community의 신뢰에 직접 영향을 줍니다.

Cominciamo con il dire che ora la visibilità della vostra modifica è
ulteriormente cresciuta.  Ci potrebbe portare ad una nuova fase di
commenti dagli sviluppatori che non erano ancora a conoscenza della vostra
patch.  Ignorarli potrebbe essere allettante dato che non ci sono più
dubbi sull'integrazione della modifica.  Resistete a tale tentazione, dovete
mantenervi disponibili agli sviluppatori che hanno domande o suggerimenti
per voi.

Ancora più importante: l'inclusione nel ramo principale mette il vostro
codice nelle mani di un gruppo di *tester* molto più esteso.  Anche se avete
contribuito ad un driver per un hardware che non è ancora disponibile, sarete
sorpresi da quante persone inseriranno il vostro codice nei loro kernel.
E, ovviamente, dove ci sono *tester*, ci saranno anche dei rapporti su
eventuali bachi.

La peggior specie di rapporti sono quelli che indicano delle regressioni.
Se la vostra modifica causa una regressione, avrete un gran numero di
occhi puntati su di voi; la regressione deve essere sistemata il prima
possibile.  Se non vorrete o non sarete capaci di sistemarla (e nessuno
lo farà per voi), la vostra modifica sarà quasi certamente rimossa durante
la fase di stabilizzazione.  Oltre alla perdita di tutto il lavoro svolto
per far si che la vostra modifica fosse inserita nel ramo principale,
l'avere una modifica rimossa a causa del fallimento nel sistemare una
regressione, potrebbe rendere più difficile per voi far accettare
il vostro lavoro in futuro.

Dopo che ogni regressione è stata affrontata, ci potrebbero essere altri
bachi ordinari da "sconfiggere".  Il periodo di stabilizzazione è la
vostra migliore opportunità per sistemare questi bachi e assicurarvi che
il debutto del vostro codice nel ramo principale del kernel sia il più solido
possibile.  Quindi, per favore, rispondete ai rapporti sui bachi e ponete
rimedio, se possibile, a tutti i problemi.  È a questo che serve il periodo
di stabilizzazione; potete iniziare creando nuove fantastiche modifiche
una volta che ogni problema con le vecchie sia stato risolto.

Non dimenticate che esistono altre pietre miliari che possono generare
rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione
importante usa una versione del kernel nel quale è presente la vostra
modifica, eccetera.  Il continuare a rispondere a questi rapporti è fonte di
orgoglio per il vostro lavoro.  Se questa non è una sufficiente motivazione,
allora, è anche consigliabile considera che la comunità di sviluppo ricorda
gli sviluppatori che hanno perso interesse per il loro codice una volta
integrato.  La prossima volta che pubblicherete una patch, la comunità
la valuterà anche sulla base del fatto che non sarete disponibili a
prendervene cura anche nel futuro.

자신의 code로 들어오는 변경과 경쟁 해법

누군가 자신의 code에 patch를 보내는 것은 open development의 이점이다. 동의한다면 올바른 From: line으로 authorship을 보존하고 자신의 sign-off를 추가해 subsystem maintainer에게 전달하거나 Acked-by reply를 보내 original author가 전달하게 한다.

동의하지 않는다면 이유를 정중히 설명하고 가능하면 받아들일 수 있게 만들 변경을 알려 준다. Code author와 maintainer의 반대는 무게가 있지만 절대 veto는 아니다. 좋은 작업을 이유 없이 막는다고 보이면 patch는 결국 그 사람을 우회해 mainline에 들어갈 수 있다.

다른 developer가 같은 문제에 별도 해결책을 게시하면 두 patch 중 하나만 merge될 가능성이 높다. 먼저 제출했다는 사실은 기술적으로 설득력 있는 근거가 아니다.

다른 patch가 자신의 patch를 대신해 mainline에 들어가면 문제가 해결된 것을 기쁘게 받아들이고 다음 작업으로 넘어간다. 작업이 밀려난 감정은 오래 남을 수 있지만 community는 어느 patch가 merge되었는지보다 그 상황에 어떻게 반응했는지를 더 오래 기억한다.

다른 사람이 자신의 code에 patch를 보내면 동의하는 경우 올바른 `From:`으로 authorship을 보존하고 자신의 `Signed-off-by:`를 추가해 maintainer에게 전달하거나, `Acked-by:`로 original author의 제출을 지원합니다.

동의하지 않으면 정중한 기술적 이유와 수용 가능한 변경 조건을 설명합니다. Maintainer에게 절대적인 veto 권한은 없으며 더 나은 해법이 선택되었다면 먼저 냈다는 이유를 내세우기보다 문제가 해결된 결과를 받아들이고 다음 작업으로 이동해야 합니다.

Altre cose che posso accadere
=============================

Un giorno, potreste aprire la vostra email e vedere che qualcuno vi ha
inviato una patch per il vostro codice.  Questo, dopo tutto, è uno dei
vantaggi di avere il vostro codice "là fuori".  Se siete d'accordo con
la modifica, potrete anche inoltrarla ad un manutentore di sottosistema
(assicuratevi di includere la riga "From:" cosicché l'attribuzione sia
corretta, e aggiungete una vostra firma "Signed-off-by"), oppure inviate
un "Acked-by:" e lasciate che l'autore originale la invii.

Se non siete d'accordo con la patch, inviate una risposta educata
spiegando il perché.  Se possibile, dite all'autore quali cambiamenti
servirebbero per rendere la patch accettabile da voi.  C'è una certa
riluttanza nell'inserire modifiche con un conflitto fra autore
e manutentore del codice, ma solo fino ad un certo punto.  Se siete visti
come qualcuno che blocca un buon lavoro senza motivo, quelle patch vi
passeranno oltre e andranno nel ramo principale in ogni caso. Nel kernel
Linux, nessuno ha potere di veto assoluto su alcun codice.  Eccezione
fatta per Linus, forse.

In rarissime occasioni, potreste vedere qualcosa di completamente diverso:
un altro sviluppatore che pubblica una soluzione differente al vostro
problema.  A questo punto, c'è una buona probabilità che una delle due
modifiche non verrà integrata, e il "c'ero prima io" non è considerato
un argomento tecnico rilevante.  Se la modifica di qualcun'altro rimpiazza
la vostra ed entra nel ramo principale, esiste un unico modo di reagire:
siate contenti che il vostro problema sia stato risolto e andate avanti con
il vostro lavoro.  L'avere un vostro lavoro spintonato da parte in questo
modo può essere avvilente e scoraggiante, ma la comunità ricorderà come
avrete reagito anche dopo che avrà dimenticato quale fu la modifica accettata.