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 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