[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202210141348.7UGXRUp8-lkp@intel.com>
Date: Fri, 14 Oct 2022 14:16:34 +0800
From: kernel test robot <lkp@...el.com>
To: Carlos Bilbao <carlos.bilbao@....com>, corbet@....net
Cc: kbuild-all@...ts.01.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, carlos.bilbao@....com, bilbao@...edu,
ojeda@...nel.org
Subject: Re: [PATCH 2/2] Documentation: Add HOWTO Spanish translation into
rst based build system
Hi Carlos,
I love your patch! Perhaps something to improve:
[auto build test WARNING on lwn/docs-next]
[also build test WARNING on linus/master v6.0 next-20221014]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Carlos-Bilbao/Documentation-Start-Spanish-translation-and-include-HOWTO/20221014-025417
base: git://git.lwn.net/linux.git docs-next
reproduce:
# https://github.com/intel-lab-lkp/linux/commit/85ae76004fce3a5a202bd65a506b9b8cac1b5e32
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Carlos-Bilbao/Documentation-Start-Spanish-translation-and-include-HOWTO/20221014-025417
git checkout 85ae76004fce3a5a202bd65a506b9b8cac1b5e32
make menuconfig
# enable CONFIG_COMPILE_TEST, CONFIG_WARN_MISSING_DOCUMENTS, CONFIG_WARN_ABI_ERRORS
make htmldocs
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@...el.com>
All warnings (new ones prefixed by >>):
>> Documentation/translations/sp_SP/howto.rst:186: WARNING: Title underline too short.
>> Documentation/translations/sp_SP/howto.rst:276: WARNING: Inline emphasis start-string without end-string.
>> Documentation/translations/sp_SP/howto.rst:277: WARNING: Block quote ends without a blank line; unexpected unindent.
>> Documentation/translations/sp_SP/howto.rst:560: WARNING: Bullet list ends without a blank line; unexpected unindent.
vim +186 Documentation/translations/sp_SP/howto.rst
181
182 make latexdocs
183 make epubdocs
184
185 Convertirse en un/a desarrollador/a de kernel
> 186 -------------------------------------------
187
188 Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
189 el proyecto Linux KernelNewbies:
190
191 https://kernelnewbies.org
192
193 Consiste en una útil lista de correo donde puede preguntar casi cualquier
194 tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
195 los archivos primero, antes de preguntar algo que ya ha sido respondido en
196 el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
197 en en tiempo real, y una gran cantidad de documentación útil que es útil
198 para ir aprendiendo sobre el desarrollo del kernel de Linux.
199
200 El sitio web tiene información básica sobre la organización del código,
201 subsistemas, y proyectos actuales (tanto dentro como fuera del árbol).
202 También describe alguna información logística básica, como cómo compilar
203 un kernel y aplicar un parche.
204
205 Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que
206 comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
207 acuda al proyecto Linux Kernel Janitor:
208
209 https://kernelnewbies.org/KernelJanitors
210
211 Es un gran lugar para comenzar. Describe una lista de problemas
212 relativamente simples que deben limpiarse y corregirse dentro del codigo
213 fuente del kernel de Linux árbol de fuentes. Trabajando con los
214 desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
215 para incluir su parche en el árbol del kernel de Linux, y posiblemente
216 descubrir en la dirección en que trabajar a continuación, si no tiene ya
217 una idea.
218
219 Antes de realizar cualquier modificación real al código del kernel de
220 Linux, es imperativo entender cómo funciona el código en cuestión. Para
221 este propósito, nada es mejor que leerlo directamente (lo más complicado
222 está bien comentado), tal vez incluso con la ayuda de herramientas
223 especializadas. Una de esas herramientas que se recomienda especialmente
224 es el proyecto Linux Cross-Reference, que es capaz de presentar el código
225 fuente en un formato de página web indexada y autorreferencial. Una
226 excelente puesta al día del repositorio del código del kernel se puede
227 encontrar en:
228
229 https://elixir.bootlin.com/
230
231 El proceso de desarrollo
232 ------------------------
233
234 El proceso de desarrollo del kernel de Linux consiste actualmente de
235 diferentes "branches" (ramas) con muchos distintos subsistemas específicos
236 a cada una de ellas. Las diferentes ramas son:
237
238 - El código principal de Linus (mainline tree)
239 - Varios árboles estables con múltiples major numbers
240 - Subsistemas específicos
241 - linux-next, para integración y testing
242
243 Mainline tree (Árbol principal)
244 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
245
246 El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
247 https://kernel.org o en su repo. El proceso de desarrollo es el siguiente:
248
249 - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
250 semanas, durante este período de tiempo, los maintainers pueden enviar
251 grandes modificaciones a Linus, por lo general los parches que ya se
252 han incluido en el linux-next durante unas semanas. La forma preferida
253 de enviar grandes cambios es usando git (la herramienta de
254 administración de codigo fuente del kernel, más información al respecto
255 en https://git-scm.com/), pero los parches simples también son validos.
256 - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
257 en hacer que el kernel nuevo lo más estable ("solido") posible. La
258 mayoría de los parches en este punto debe arreglar una regresión. Los
259 errores que siempre han existido no son regresiones, por lo tanto, solo
260 envíe este tipo de correcciones si son importantes. Tenga en cuenta que
261 se podría aceptar un controlador (o sistema de archivos) completamente
262 nuevo después de -rc1 porque no hay riesgo de causar regresiones con
263 tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas
264 fuera del código que se está agregando. git se puede usar para enviar
265 parches a Linus después de que se lance -rc1, pero los parches también
266 deben ser enviado a una lista de correo pública para su revisión.
267 - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
268 actual esta en un estado razonablemente sano y adecuado para la prueba.
269 La meta es lanzar un nuevo kernel -rc cada semana.
270 - El proceso continúa hasta que el kernel se considera "listo", y esto
271 puede durar alrededor de 6 semanas.
272
273 Vale la pena mencionar lo que Andrew Morton escribió en las listas de
274 correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
275
> 276 *"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
> 277 de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
278 una línea temporal preconcebida."*
279
--
0-DAY CI Kernel Test Service
https://01.org/lkp
View attachment "config" of type "text/plain" (38517 bytes)
Powered by blists - more mailing lists