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