Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
docs/sp_SP: Add translation of process/7.AdvancedTopics.rst
Translate Documentation/process/7.AdvancedTopics.rst into Spanish.
Co-developed-by: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
Signed-off-by: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Signed-off-by: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20241129155851.1023884-6-carlos.bilbao.osdev@gmail.com
authored by
Avadhut Naik
and committed by
Jonathan Corbet
b33bad52
6422b065
+206
-2
+205
-2
Documentation/translations/sp_SP/process/7.AdvancedTopics.rst
+205
-2
Documentation/translations/sp_SP/process/7.AdvancedTopics.rst
···
1
1
.. include:: ../disclaimer-sp.rst
2
2
3
3
:Original: Documentation/process/7.AdvancedTopics.rst
4
+
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>
4
5
5
6
.. _sp_development_advancedtopics:
6
7
7
8
Temas avanzados
8
9
===============
9
10
10
-
.. warning::
11
-
TODO aún no traducido
11
+
Llegados a este punto, con suerte, tiene una idea de cómo funciona el
12
+
proceso de desarrollo. Sin embargo, ¡todavía hay más que aprender! Esta
13
+
sección cubrirá varios temas que pueden ser útiles para los desarrolladores
14
+
que desean convertirse en una parte regular del proceso de desarrollo del
15
+
kernel Linux.
16
+
17
+
Gestionar parches con git
18
+
-------------------------
19
+
20
+
El uso del control de versiones distribuido para el kernel comenzó a
21
+
principios de 2002 cuando Linus comenzó a jugar con la aplicación
22
+
propietaria BitKeeper. Aunque BitKeeper fue controvertido, el enfoque de
23
+
la gestión de versiones de software que incorporó ciertamente no lo fue.
24
+
El control de versiones distribuido permitió una aceleración inmediata
25
+
del proyecto de desarrollo del kernel. En los tiempos actuales, existen
26
+
varias alternativas gratuitas a BitKeeper. Para bien o para mal, el
27
+
proyecto del kernel ha optado por git como su herramienta preferida.
28
+
29
+
Administrar parches con git puede hacer la vida mucho más fácil para el
30
+
desarrollador, especialmente a medida que crece el volumen de esos
31
+
parches. Git también tiene sus asperezas y representa ciertos peligros;
32
+
es una herramienta joven y poderosa que aún está siendo civilizada por
33
+
sus desarrolladores. Este documento no intentará enseñar al lector cómo
34
+
usar git; eso sería material suficiente para un documento extenso por
35
+
derecho propio. En su lugar, el enfoque aquí será cómo git encaja en el
36
+
proceso de desarrollo del kernel en particular. Los desarrolladores que
37
+
deseen ponerse al día con git encontrarán más información en:
38
+
39
+
https://git-scm.com/
40
+
41
+
https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
42
+
43
+
y en varios tutoriales que se encuentran en la web.
44
+
45
+
El primer orden del negocio es leer los sitios mencionados anteriormente
46
+
y comprender cómo funciona git antes de intentar usarlo para poner
47
+
parches a disposición de otros. Un desarrollador que usa git debe ser
48
+
capaz de obtener una copia del repositorio mainline, explorar el historial
49
+
de revisiones, hacer commits en el árbol, usar ramas, etcétera. También es
50
+
útil entender las herramientas de git para rescribir la historia (como
51
+
rebase). Git viene con su propia terminología y conceptos; un nuevo
52
+
usuario de git debe conocer las referencias, las ramas remotas, el índice,
53
+
las fusiones fast-forward, los pushes y pulls, las cabezas separadas,
54
+
etcétera. Todo puede ser un poco intimidante al principio, pero los
55
+
conceptos no son tan difíciles de entender con un poco de estudio.
56
+
57
+
Usar git para generar parches para enviarlos por correo electrónico puede
58
+
ser un buen ejercicio mientras te pones al día.
59
+
60
+
Cuando esté listo para comenzar a publicar árboles de git para que otros
61
+
los vean, necesitará por supuesto, un servidor del que se pueda extraer.
62
+
Configurar un servidor de este tipo con git-daemon es relativamente
63
+
sencillo si tiene un sistema accesible a Internet. De lo contrario, los
64
+
sitios de alojamiento público y gratuitos (GitHub, por ejemplo) están
65
+
comenzando a aparecer en la red. Los desarrolladores establecidos pueden
66
+
obtener una cuenta en kernel.org, pero no son fáciles de conseguir; ver
67
+
https://kernel.org/faq/ para más información.
68
+
69
+
El flujo de trabajo normal de git implica el uso de muchas ramas. Cada
70
+
línea de desarrollo puede separarse en una “rama temática” separada y
71
+
mantenerse de forma independiente. Las ramas en git son baratas, no hay
72
+
razón para no hacer uso gratuito de ellas. Y, en cualquier caso, no debe
73
+
desarrollarse en ninguna rama de la que tenga la intención de pedir a
74
+
otros que hagan un pull. Las ramas disponibles públicamente deben crearse
75
+
con cuidado; fusione los parches de las ramas de desarrollo cuando estén
76
+
en forma completa y listos para usar – no antes.
77
+
78
+
Git proporciona herramientas poderosas que permiten reescribir su historia
79
+
de desarrollo. Un parche inconveniente (uno que rompe la bisección, por
80
+
ejemplo, o que tiene algún otro tipo de error obvio) se puede corregir en
81
+
su lugar o hacer que desaparezca de la historia por completo. Una serie de
82
+
parches se puede reescribir como si se hubiera escrito sobre el mainline
83
+
de hoy, aunque haya estado trabajando en ella durante meses. Los cambios
84
+
se pueden transferir de manera transparente de una rama a otra. Y así
85
+
sucesivamente. El uso juicioso de la capacidad de git para revisar el
86
+
historial puede ayudar en la creación de conjuntos de parches limpios con
87
+
menos problemas.
88
+
89
+
El uso excesivo de esta capacidad puede llevar a otros problemas más allá
90
+
de una simple obsesión por crear la historia perfecta del proyecto.
91
+
Reescribir la historia rescribirá los cambios contenidos en esa historia,
92
+
convirtiendo un árbol del kernel probado (con suerte) en uno no probado.
93
+
Pero más allá de eso, los desarrolladores no pueden colaborar fácilmente
94
+
si no tienen una vista compartida del historial del proyecto; si reescribe
95
+
la historia que otros desarrolladores han introducido en sus repositorios,
96
+
les hará la vida mucho más difícil a esos desarrolladores. Por lo tanto,
97
+
aquí se aplica una regla simple general: la historia que se ha exportado
98
+
a otros generalmente debe considerarse inmutable a partir de entonces.
99
+
100
+
Por lo tanto, una vez que envié un conjunto de cambios a su servidor
101
+
disponible públicamente, esos cambios no deben reescribirse. Git
102
+
intentará hacer cumplir esta regla si intenta enviar cambios que no
103
+
resulten en un “fast-forward merge” (es decir, cambios que no comparten
104
+
el mismo historial). Es posible anular esta comprobación, y puede haber
105
+
ocasiones en las que sea necesario reescribir un árbol exportado. Mover
106
+
conjuntos de cambios entre árboles para evitar conflictos en linux-next
107
+
es un ejemplo. Pero tales acciones deberían ser raras. Esta es una de las
108
+
razones por las que el desarrollo debe hacerse en ramas privadas (que se
109
+
pueden reescribir si es necesario) y solo trasladarse a ramas públicas
110
+
cuando esté en un estado razonablemente avanzado.
111
+
112
+
A medida que el mainline (u otro árbol en el que se basa un conjunto de
113
+
cambios) avanza, es tentador fusionarse con ese árbol para permanecer a
114
+
la vanguardia. Para una rama privada, la rebase puede ser una manera fácil
115
+
de mantenerse al día con otro árbol, pero la rebase no es una opción una
116
+
vez que el árbol se exporta al mundo. Una vez que eso sucede, se debe
117
+
realizar una fusión completa. Fusionar ocasionalmente tiene sentido, pero
118
+
las fusiones demasiado frecuentes pueden desordenar el historial
119
+
innecesariamente. La técnica sugerida en este caso es fusionar con poca
120
+
frecuencia y, por lo general, solo en puntos de lanzamiento específicos
121
+
(como una versión -rc del mainline). Si está nervioso por cambios
122
+
específicos, siempre puede realizar fusiones de prueba en una rama
123
+
privada. La herramienta git “rerere” puede ser útil en tales situaciones;
124
+
recuerda cómo se resolvieron los conflictos de fusión para que no tenga
125
+
que hacer el mismo trabajo dos veces.
126
+
127
+
Una de las mayores quejas recurrentes sobre herramientas como git es la
128
+
siguiente: el movimiento masivo de parches de un repositorio a otro hace
129
+
que sea fácil deslizar cambios más aconsejados que pasan al mainline
130
+
debajo del radar de revisión. Los desarrolladores del kernel tienden a
131
+
descontentarse cuando ven que suceden ese tipo de cosas; poner un árbol
132
+
de git con parches no revisados o fuera de tema puede afectar su capacidad
133
+
para hacer que los árboles sean integrados en el futuro. Citando a Linus:
134
+
135
+
::
136
+
137
+
Puede enviarme parches, pero para que yo acepte un parche de git de
138
+
su parte, necesito saber que usted sabe lo que está haciendo, y
139
+
necesito poder confiar en las cosas *sin* tener que revisar
140
+
manualmente cada cambio individual.
141
+
142
+
(https://lwn.net/Articles/224135/).
143
+
144
+
Para evitar este tipo de situación, asegúrese de que todos los parches
145
+
dentro de una rama determinada se adhieran estrictamente al tema asociado;
146
+
una rama de “correcciones de drivers” no debería hacer cambios en el
147
+
código central de gestión de memoria. Y, lo más importante, no utilice un
148
+
árbol git para eludir el proceso de revisión. Publique un resumen
149
+
ocasional del árbol en la lista relevante y, cuando sea el momento
150
+
adecuado, solicite que el árbol se incluya en linux-next.
151
+
152
+
Si y cuando otros comiencen a enviar parches para su inclusión en su
153
+
árbol, no olvide revisarlos. Además, asegúrese de mantener la información
154
+
de autoría correcta; la herramienta git “am” hace lo mejor que puede es
155
+
este sentido, pero es posible que tenga que agregar una línea “From:” al
156
+
parche si ha sido reenviado a través de un tercero.
157
+
158
+
Al solicitar un pull, proporcione toda la información relevante: dónde
159
+
está su árbol, qué rama se debe pull, y que cambios resultarán del pull.
160
+
El comando git request-pull puede ser útil en este sentido; formateará la
161
+
solicitud como otros desarrolladores esperan, y también comprobará para
162
+
asegurarse de que ha recordado enviar esos cambios al servidor público.
163
+
164
+
Revisión de parches
165
+
-------------------
166
+
167
+
Algunos lectores seguramente se opondrán a incluir esta sección con
168
+
“temas avanzados” porque incluso los desarrolladores principiantes del
169
+
kernel deberían revisar los parches. Es cierto que no hay mejor manera de
170
+
aprender a programar en el entorno del kernel que mirando el código
171
+
publicado por otros. Además, los revisores siempre escasean; al revisar
172
+
código, puede contribuir significativamente al proceso en su conjunto.
173
+
174
+
Revisar el código puede ser una perspectiva intimidante, especialmente
175
+
para un nuevo desarrollador de kernel que puede sentirse nervioso al
176
+
cuestionar el código – en público – publicado por aquellos con más
177
+
experiencia. Sin embargo, incluso el código escrito por los desarrolladores
178
+
más experimentados se puede mejorar. Quizás el mejor consejo para los
179
+
revisores (todos los revisores) es este: expresar los comentarios de
180
+
revisión como preguntas en lugar de críticas. Preguntar “¿cómo se libera
181
+
el bloqueo en este camino?” siempre funcionará mejor que decir “el
182
+
bloqueo aquí es incorrecto”.
183
+
184
+
Otra técnica que es útil en caso de desacuerdo es pedir a otros que
185
+
intervengan. Si una discusión llega a un punto muerto después de algunos
186
+
intercambios, solicite las opiniones de otros revisores o maintainers. A
187
+
menudo, aquellos que están de acuerdo con un revisor permanecen en
188
+
silencio a menos que se les invite a participar. La opinión de varias
189
+
personas tiene exponencialmente más peso.
190
+
191
+
Diferentes desarrolladores revisarán el código desde diferentes puntos de
192
+
vista. Algunos se preocupan principalmente por el estilo de codificación
193
+
y si las líneas de código tienen espacios en blanco al final. Otros se
194
+
enfocarán principalmente en si el cambio implementado por el parche en su
195
+
totalidad es beneficioso para el kernel o no. Sin embargo, otros
196
+
comprobarán si hay bloqueos problemáticos, uso excesivo de la pila,
197
+
posibles problemas de seguridad, duplicación de código encontrado en
198
+
otras partes, documentación adecuada, efectos adversos en el rendimiento,
199
+
cambios en la ABI del espacio de usuario, etcétera. Todos los tipos de
200
+
revisión, si conducen a un mejor código en el kernel, son bienvenidos y
201
+
valen la pena.
202
+
203
+
No hay ningún requisito estricto para usar etiquetas específicas como
204
+
``Reviewed-by``. De hecho, las revisiones en Inglés sencillo son más
205
+
informativas y alentadas incluso cuando se proporciona una etiqueta, por
206
+
ejemplo, “Revisé los aspectos A, B y C de esta propuesta y me parece
207
+
bien”.
208
+
¡Alguna forma de mensaje de revisión o respuesta es obviamente necesaria,
209
+
de lo contrario, los maintainers no sabrán que el revisor ha revisado el
210
+
parche en absoluto!
211
+
212
+
Por último, pero no menos importante, la revisión de parches puede
213
+
convertirse en un proceso negativo, centrado en señalar problemas. ¡Por
214
+
favor, dé un cumplido de vez en cuando, especialmente a los principiantes!