543 lines · plain
1.. include:: ../disclaimer-sp.rst2 3:Original: Documentation/process/2.Process.rst4:Translator: Avadhut Naik <avadhut.naik@amd.com>5 6.. _sp_development_process:7 8Cómo funciona el proceso de desarrollo9======================================10 11El desarrollo del kernel de Linux a principios de la década de 1990 fue12un asunto relajado, con un número relativamente pequeño de usuarios y13desarrolladores involucrados. Con una base de usuarios en los millones y14alrededor de 2,000 desarrolladores involucrados durante un año, el kernel15ha tenido que adaptar varios procesos para mantener el desarrollo sin16problemas. Se requiere una comprensión solida de cómo funciona el proceso17para ser una parte efectiva del mismo.18 19El panorama general20-------------------21 22Los desarrolladores del kernel utilizan un proceso de lanzamiento basado23en el tiempo de manera flexible, con uno nuevo lanzamiento principal del24kernel ocurriendo cada dos o tres meses. El historial reciente de25lanzamientos se ve así:26 27 ====== ==================28 5.0 Marzo 3, 201929 5.1 Mayo 5, 201930 5.2 Julio 7, 201931 5.3 Septiembre 15, 201932 5.4 Noviembre 24, 201933 5.5 Enero 6, 202034 ====== ==================35 36Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas37características, cambios internos en la API y más. Un lanzamiento típico38puede contener alrededor de 13,000 conjuntos de cambios incluyendo en39varias centenas de miles de líneas de código. 5.x es la vanguardia del40desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo41continuo que está integrando continuamente cambios importantes.42 43Se sigue una disciplina relativamente sencilla con respecto a la fusión44de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo,45se dice que la "merge window" (ventana de fusión) está abierta. En ese46momento, el código que se considera lo suficientemente estable (y que es47aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.48La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos49los cambios principales) se fusionarán durante este tiempo, a un ritmo50cercano a los 1,000 cambios (“parches” o “conjuntos de cambios”) por51día.52 53(Aparte, vale la pena señalar que los cambios integrados durante la54ventana de fusión no surgen de la nada; han sido recolectados, probados55y montados con anticipación. Como funciona ese proceso se describirá en56detalle más adelante).57 58La ventana de fusión dura aproximadamente dos semanas. Al final de este59tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará60el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por61ejemplo, el lanzamiento al final de la ventana de fusión se llamará625.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas63características ha pasado y que el tiempo para estabilizar el siguiente64kernel ha comenzado.65 66Durante las próximas seis a diez semanas, solo los parches que solucionen67problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio68más significativo, pero tales ocasiones son raras; los desarrolladores que69intentan fusionar nuevas características fuera de la ventana de fusión70suelen recibir una recepción poco amistosa. Como regla general, si se71pierde la ventana de fusión de una característica determinada, lo mejor72que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una73excepción ocasional para los drivers de hardware que no se admitía74anteriormente; si no afectan a ningún código en árbol, no pueden causar75regresiones y debería ser seguro agregarlos en cualquier momento).76 77A medida que las correcciones se abren paso en el mainline, la tasa de78parches se ralentizará con el tiempo. Linus lanza nuevos kernels -rc79aproximadamente una vez a la semana; una serie normal llegará a algún80punto entre -rc6 y -rc9 antes de que se considere que el kernel es81suficientemente estable y realice el lanzamiento final. En ese momento,82todo el proceso vuelve a empezar.83 84Como ejemplo, así fue el ciclo de desarrollo de 5.4 (todas las fechas son85de 2019):86 87 ============== =======================================88 Septiembre 15 5.3 lanzamiento estable89 Septiembre 30 5.4-rc1, la ventana de fusion se cierra90 Octubre 6 5.4-rc291 Octubre 13 5.4-rc392 Octubre 20 5.4-rc493 Octubre 27 5.4-rc594 Noviembre 3 5.4-rc695 Noviembre 10 5.4-rc796 Noviembre 17 5.4-rc897 Noviembre 24 5.4 lanzamiento estable98 ============== =======================================99 100¿Cómo deciden los desarrolladores cuándo cerrar el ciclo de desarrollo101y crear el lanzamiento estable? La métrica más significativa utilizada102es la lista de regresiones de lanzamientos anteriores. Ningunos errores103son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el104pasado se consideran especialmente graves. Por esta razón, los parches105que causan regresiones se ven con malos ojos y es bastante probable que106se reviertan durante el periodo de estabilización.107 108El objetivo de los desarrolladores es corregir todas las regresiones109conocidas antes de que se realice el lanzamiento estable. En el mundo110real, este tipo de perfección es difícil de lograr; hay demasiados111variables en un proyecto de este tamaño. Llega un punto en el que112retrasar el lanzamiento final solo empeora el problema; la pila de cambios113que esperan la siguiente ventana de fusión crecerá, creando aún más114regresiones la próxima vez. Por lo tanto, la mayoría de los kernels 5.x115se lanzan con un punado de regresiones conocidas, aunque, con suerte,116ninguna de ellas es seria.117 118Una vez que se realiza un lanzamiento estable, su mantenimiento continuo119se transfiere al “equipo estable”, actualmente encabezado por Greg120Kroah-Hartman. El equipo estable lanzará actualizaciones ocasionales al121lanzamiento estable utilizando el esquema de numeración 5.x.y. Para ser122considerado para un lanzamiento de actualización, un parche debe123(1) corregir un error significativo y (2) ya estar fusionado en el124mainline para el siguiente kernel de desarrollo. Por lo general, los125kernels recibirán actualizaciones estables durante un poco más de un126ciclo de desarrollo después de su lanzamiento inicial. Así, por ejemplo,127la historia del kernel 5.2 se veía así (todas las fechas en 2019):128 129 ============== ===============================130 Julio 7 5.2 lanzamiento estable131 Julio 14 5.2.1132 Julio 21 5.2.2133 Julio 26 5.2.3134 Julio 28 5.2.4135 Julio 31 5.2.5136 ... ...137 Octubre 11 5.2.21138 ============== ===============================139 1405.2.21 fue la última actualización estable del lanzamiento 5.2.141 142Algunos kernels se designan como kernels “a largo plazo”; recibirán143soporte durante un periodo más largo. Consulte el siguiente enlace para144obtener la lista de versiones activas del kernel a largo plazos y sus145maintainers:146 147 https://www.kernel.org/category/releases.html148 149La selección de un kernel para soporte a largo plazo es puramente una150cuestión de que un maintainer tenga la necesidad y el tiempo para151mantener ese lanzamiento. No hay planes conocidos para ofrecer soporte a152largo plazo para ningún lanzamiento especifico próximo.153 154Ciclo de vida de un parche155--------------------------156 157Los parches no van directamente desde el teclado del desarrollador al158kernel mainline. Hay, en cambio, un proceso algo complicado (aunque algo159informal) diseñado para garantizar que cada parche sea revisado en cuanto160a calidad y que cada parche implemente un cambio que es deseable tener en161el mainline. Este proceso puede ocurrir rápidamente para correcciones162menores, o, en el caso de cambios grandes y controvertidos, continuar163durante años. Gran parte de la frustración de los desarrolladores proviene164de la falta de compresión de este proceso o de sus intentos de eludirlo.165 166Con la esperanza de reducir esa frustración, este documento describirá167cómo un parche entra en el kernel. Lo que sigue a continuación es una168introducción que describe el proceso de una manera tanto idealizada. Un169tratamiento mucho más detallado vendrá en secciones posteriores.170 171Las etapas por las que pasa un parche son, generalmente:172 173 - Diseño. Aquí es donde se establecen los requisitos reales para el174 parche – y la forma en que se cumplirán esos requisitos. El trabajo175 de diseño a menudo se realiza sin involucrar a la comunidad, pero es176 mejor hacer este trabajo de manera abierta si es posible; puede ahorrar177 mucho tiempo rediseñando las cosas más tarde.178 179 - Revisión inicial. Los parches se publican en la lista de correo180 relevante y los desarrolladores en esa lista responden con cualquier181 comentario que puedan tener. Este proceso debería revelar cualquier182 problema importante con un parche si todo va bien.183 184 - Revisión más amplia. Cuando el parche se acerca a estar listo para su185 inclusión en el mainline, debe ser aceptado por un maintainer del186 subsistema relevante – aunque esta aceptación no es una garantía de187 que el parche llegara hasta el mainline. El parche aparecerá en el188 árbol de subsistemas del maintainer y en los árboles -next (descritos189 a continuación). Cuando el proceso funciona, este paso conduce a una190 revisión exhaustiva del parche y al descubrimiento de cualquier191 problema resultante de la integración de este parche con el trabajo192 realizado por otros.193 194 - Tenga en cuenta que la mayoría de los maintainers también tienen195 trabajos diurnos, por lo que fusionar su parche no puede ser su máxima196 prioridad. Si su parche está recibiendo comentarios sobre los cambios197 que se necesitan, debería realizar esos cambios o justificar por qué198 no deberían realizarse. Si su parche no tiene quejas de revisión, pero199 no está siendo fusionado por el maintainer apropiado del subsistema o200 del driver, debe ser persistente en la actualización del parche201 al kernel actual para que se aplique limpiamente y seguir enviándolo202 para su revisión y fusión.203 204 - Fusión en el mainline. Eventualmente, un parche exitoso se fusionará205 en el repositorio mainline administrado por Linux Torvalds. Mas206 comentarios y/o problemas pueden surgir en este momento; es importante207 que el desarrollador responda a estos y solucione cualquier problema208 que surja.209 210 - Lanzamiento estable. El número de usuarios potencialmente afectados por211 el parche es ahora grande, por lo que, una vez más, pueden surgir212 nuevos problemas.213 214 - Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse215 del código después de fusionarlo, ese comportamiento tiende a dejar216 una impresión negativa en la comunidad de desarrollo. Fusionar el217 código elimina parte de la carga de mantenimiento; otros solucionarán218 los problemas causados por los cambios en la API. Sin embargo, el219 desarrollador original debe seguir asumiendo la responsabilidad del220 código si quiere seguir siendo útil a largo plazo.221 222Uno de los peores errores cometidos por los desarrolladores del kernel223(o sus empleadores) es tratar de reducir el proceso a un solo paso de224“fusión en el mainline”. Este enfoque conduce invariablemente a la225frustración de todos los involucrados.226 227Cómo se integran los parches en el kernel228-----------------------------------------229 230Hay exactamente una persona que puede fusionar parches en el repositorio231mainline del kernel: Linus Torvalds. Pero, por ejemplo, de los más de2329,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor233del 1.3%) fueron elegidos directamente por Linus mismo. El proyecto del234kernel ha crecido mucho desde hace tiempo a un tamaño en el que ningún235desarrollador individual podría inspeccionar y seleccionar todos los236parches sin ayuda. La forma que los desarrolladores del kernel han237abordado este crecimiento es a través del uso de un sistema jerárquico238alrededor de una cadena de confianza.239 240La base de código del kernel se descompone lógicamente en un conjunto de241subsistemas: redes, soporte de arquitectura especifica, gestión de242memoria, dispositivos de video, etc. La mayoría de los subsistemas tienen243un maintainer designado, un desarrollador que tiene la responsabilidad244general del código dentro de ese subsistema. Estos maintainers de245subsistemas son los guardianes (en cierto modo) de la parte del kernel que246gestionan; son los que (usualmente) aceptarán un parche para incluirlo en247el kernel mainline.248 249Cada uno de los maintainers del subsistema administra su propia versión250del árbol de fuentes del kernel, generalmente (pero, ciertamente no251siempre) usando la herramienta de administración de código fuente de git.252Herramientas como git (y herramientas relacionadas como quilt o mercurial)253permiten a los maintainers realizar un seguimiento de una lista de254parches, incluida la información de autoría y otros metadatos. En255cualquier momento, el maintainer puede identificar qué parches de su256repositorio no se encuentran en el mainline.257 258Cuando se abre la ventana de fusión, los maintainers de nivel superior259le pedirán a Linus que “extraiga” los parches que han seleccionado para260fusionar de sus repositorios. Si Linus está de acuerdo, el flujo de261parches fluirá hacia su repositorio, convirtiéndose en parte del kernel262mainline. La cantidad de atención que Linus presta a los parches263específicos recibidos en una operación de extracción varia. Está claro264que, a veces, examina bastante de cerca. Pero, como regla general, Linus265confía en que los maintainers del subsistema no envíen parches266defectuosos al upstream.267 268Los maintainers de subsistemas, a su vez, pueden extraer parches de otros269maintainers. Por ejemplo, el árbol de red se construye a partir de270parches que se acumulan primero en arboles dedicados a drivers de271dispositivos de red, redes inalámbricas, etc. Esta cadena de repositorios272puede ser arbitrariamente larga, aunque rara vez supera los dos o tres273enlaces. Dado que cada maintainer de la cadena confía en los que274administran árboles de nivel inferior, este proceso se conoce como la275“cadena de confianza”.276 277Claramente, en un sistema como este, lograr que los parches se integren278en el kernel depende de encontrar el maintainer adecuado. Enviar parches279directamente a Linus no es normalmente la forma correcta de hacerlo.280 281Árboles siguientes (next)282-------------------------283 284La cadena de árboles de subsistemas guía el flujo de parches en el285kernel, pero también plantea una pregunta interesante: ¿Qué pasa si286alguien quiere ver todos los parches que se están preparando para la287próxima ventana de fusión? Los desarrolladores estarán interesados en288saber que otros cambios están pendientes para ver si hay algún conflicto289del que preocuparse; un parche que cambia un prototipo de función del290núcleo del kernel, por ejemplo, entrará en conflicto con cualquier otro291parche que utilice la forma anterior de esa función. Los revisores y292probadores quieren tener acceso a los cambios en su forma integrada antes293de que todos esos cambios se integren en el kernel mainline. Uno podría294extraer cambios de todos los árboles de subsistemas interesantes, pero295eso sería un trabajo tedioso y propenso a errores.296 297La respuesta viene en forma de árboles -next, donde los árboles de298subsistemas se recopilan para pruebas y revisiones. El más antiguo de299estos árboles, mantenido por Andrew Morton, se llama “-mm” (por gestión300de la memoria, que es como comenzó). El árbol “-mm” integra parches301de una larga lista de árboles de subsistemas; también tiene algunos302parches destinados a ayudar con la depuración.303 304Más allá de eso, -mm contiene una colección significativa de parches305que han sido seleccionados directamente por Andrew. Estos parches pueden306haber sido publicados en una lista de correo o aplicarse a una parte del307kernel para la que no hay un árbol de subsistemas designado. Como308resultado, -mm funciona como una especie de árbol de subsistemas de309último recurso; si no hay otro camino obvio para un parche en el mainline,310es probable que termine en -mm. Los parches misceláneos que se acumulan311en -mm eventualmente se enviarán a un árbol de subsistema apropiado o se312enviarán directamente a Linus. En un ciclo de desarrollo típico,313aproximadamente el 5-10% de los parches que van al mainline llegan allí314a través de -mm.315 316El parche -mm actual está disponible en el directorio “mmotm” (-mm317del momento) en:318 319 https://www.ozlabs.org/~akpm/mmotm/320 321Sin embargo, es probable que el uso del árbol MMOTM sea una experiencia322frustrante; existe una posibilidad definitiva de que ni siquiera se323compile.324 325El árbol principal para la fusión de parches del siguiente ciclo es326linux-next, mantenido por Stephen Rothwell. El árbol linux-next es, por327diseño, una instantánea de cómo se espera que se vea el mainline después328de que se cierre la siguiente ventana de fusión. Los árboles linux-next329se anuncian en las listas de correo linux-kernel y linux-next cuando se330ensamblan; Se pueden descargar desde:331 332 https://www.kernel.org/pub/linux/kernel/next/333 334Linux-next se ha convertido en una parte integral del proceso de335desarrollo del kernel; todos los parches fusionados durante una ventana336de fusión determinada deberían haber encontrado su camino en linux-next337en algún momento antes de que se abra la ventana de fusión.338 339Árboles de staging340------------------341 342El árbol de fuentes del kernel contiene el directorio drivers/staging/,343donde residen muchos subdirectorios para drivers o sistemas de archivos344que están en proceso de ser agregados al árbol del kernel. Permanecen345en drivers/staging mientras aún necesitan más trabajo; una vez346completados, se pueden mover al kernel propiamente dicho. Esta es una347forma de realizar un seguimiento de los drivers drivers que no están a la348altura de la codificación o los estándares de calidad del kernel de349Linux, pero que las personas pueden querer usarlos y realizar un350seguimiento del desarrollo.351 352Greg Kroah-Hartman mantiene actualmente el árbol de staging. Los drivers353que aun necesitan trabajo se le envían, y cada driver tiene su propio354subdirectorio en drivers/staging/. Junto con los archivos de origen del355driver, también debe haber un archivo TODO en el directorio. El archivo356TODO enumera el trabajo pendiente que el driver necesita para ser aceptado357en el kernel propiamente dicho, así como una lista de personas a las que358Cc’d para cualquier parche para el driver. Las reglas actuales exigen359que los drivers que contribuyen a staging deben, como mínimo, compilarse360correctamente.361 362El staging puede ser una forma relativamente fácil de conseguir nuevos363drivers en el mainline donde, con suerte, llamarán la atención de otros364desarrolladores y mejorarán rápidamente. Sin embargo, la entrada en el365staging no es el final de la historia; el código que no está viendo366progreso regular eventualmente será eliminado. Los distribuidores también367tienden a ser relativamente reacios a habilitar los drivers de staging.368Por lo tanto, el staging es, en el mejor de los casos, una parada en el369camino para hacia convertirse en un apropiado driver del mainline.370 371Herramientas372------------373 374Como se puede ver en el texto anterior, el proceso de desarrollo del375kernel depende en gran medida de la capacidad de dirigir colecciones de376parches en varias direcciones. Todo ello no funcionaría tan bien como lo377hace sin herramientas apropiadamente potentes. Los tutoriales sobre cómo378usar estas herramientas están mucho más allá del alcance de este379documento, pero hay espacio para algunos consejos.380 381Con mucho, el sistema de gestión de código fuente dominante utilizado382por la comunidad del kernel es git. Git es uno de los varios sistemas de383control de versiones distribuidos que se están desarrollando en la384comunidad de software libre. Está bien ajustado para el desarrollo de385kernel, ya que funciona bastante bien cuando se trata de grandes386repositorios y grandes cantidades de parches. También tiene la reputación387de ser difícil de aprender y usar, aunque ha mejorado con el tiempo.388Algún tipo de familiaridad con git es casi un requisito para los389desarrolladores del kernel; incluso si no lo usan para su propio390trabajo, necesitarán git para mantenerse al día con lo que otros391desarrolladores (y el mainline) están haciendo.392 393Git ahora está empaquetado por casi todas las distribuciones de Linux.394Hay una página de inicio en:395 396 https://git-scm.com/397 398Esa página tiene punteros a documentación y tutoriales.399 400Entre los desarrolladores de kernel que no usan git, la opción más401popular es casi con certeza Mercurial:402 403 https://www.selenic.com/mercurial/404 405Mercurial comparte muchas características con git, pero proporciona una406interfaz que muchos encuentran más fácil de usar.407 408Otra herramienta que vale la pena conocer es Quilt:409 410 https://savannah.nongnu.org/projects/quilt/411 412Quilt es un sistema de gestión de parches, en lugar de un sistema de413gestión de código fuente. No rastrea el historial a lo largo del tiempo;414en cambio, está orientado al seguimiento de un conjunto especifico de415cambios en relación con una base de código en evolución. Algunos de los416principales maintainers de subsistemas utilizan Quilt para gestionar los417parches destinados a ir upstream. Para la gestión de ciertos tipos de418árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo.419 420Listas de correo421----------------422 423Una gran parte del trabajo de desarrollo del kernel de Linux se realiza a424través de listas de correo. Es difícil ser un miembro plenamente funcional425de la comunidad sin unirse al menos a una lista en algún parte. Pero las426listas de correo de Linux también representan un peligro potencial para427los desarrolladores, que corren el riesgo de quedar enterrados bajo una428carga de correo electrónico, incumplir las convenciones utilizadas en las429listas de Linux, o ambas cosas.430 431La mayoría de las listas de correo del kernel se ejecutan en432vger.kernel.org; la lista principal se puede encontrar en:433 434 http://vger.kernel.org/vger-lists.html435 436Sim embargo, hay listas alojadas en otros lugares; varios de ellos se437encuentran en redhat.com/mailman/listinfo.438 439La lista de correo principal para el desarrollo del kernel es, por440supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen441puede alcanzar 500 mensajes por día, la cantidad de ruido es alta, la442conversación puede ser muy técnica y los participantes no siempre se443preocupan por mostrar un alto grado de cortesía. Pero no hay otro lugar444donde la comunidad de desarrollo del kernel se reúna como un todo; los445desarrolladores que eviten esta lista se perderán información importante.446 447Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux:448 449- Haga que la lista se entregue en una carpeta separada, en lugar de su450 buzón principal. Uno debe ser capaz de ignorar el flujo durante451 periodos prolongados.452 453- No trate de seguir cada conversación, nadie lo hace. Es importante454 filtrar tanto por el tema de interés (aunque tenga en cuenta que las455 conversaciones prolongadas pueden alejarse del asunto original sin456 cambiar la línea de asunto del correo electrónico) por las personas457 que participan.458 459- No alimente a los trolls. Si alguien está tratando de provocar una460 respuesta de enojo, ignórelos.461 462- Al responder al correo electrónico del kernel de Linux (o al de otras463 listas) conserve el encabezado Cc: para todos los involucrados. En464 ausencia de una razón solida (como una solicitud explícita), nunca debe465 eliminar destinarios. Asegúrese siempre de que la persona a la que está466 respondiendo esté en la lista Cc:. Esta convención también hace que no467 sea necesario solicitar explícitamente que se le copie en las respuestas468 a sus publicaciones.469 470- Busque en los archivos de la lista (y en la red en su conjunto) antes471 de hacer preguntas. Algunos desarrolladores pueden impacientarse con472 las personas que claramente no han hecho sus deberes.473 474- Utilice respuestas intercaladas (“en línea”), lo que hace que su475 respuesta sea más fácil de leer. (Es decir, evite top-posting – la476 práctica de poner su respuesta encima del texto citado al que está477 respondiendo.) Para obtener más información, consulte478 :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_interleaved_replies>`.479 480- Pregunte en la lista de correo correcta. linux-kernel puede ser el481 punto de encuentro general, pero no es el mejor lugar para encontrar482 desarrolladores de todos los subsistemas.483 484El último punto, encontrar la lista de correo correcta, es una fuente485común de errores para desarrolladores principiantes. Alguien que haga486una pregunta relacionada con las redes en linux-kernel seguramente487recibirá una surgencia educada para preguntar en la lista de netdev en su488lugar, ya que esa es la lista frecuentada por la mayoría de los489desarrolladores de redes. Existen otras listas para los subsistemas SCSI,490video4linux, IDE, sistema de archivos, etc. El mejor lugar para buscar491listas de correo es en el archivo MAINTAINERS incluido con el código492fuente del kernel.493 494Comenzar con el desarrollo del kernel495-------------------------------------496 497Las preguntas sobre como comenzar con el proceso de desarrollo del kernel498son comunes, tanto de individuos como de empresas. Igualmente comunes son499los pasos en falso que hacen que el comienzo de la relación sea más500difícil de lo que tiene que ser.501 502Las empresas a menudo buscan contratar desarrolladores conocidos para503iniciar un grupo de desarrollo. De hecho, esta puede ser una técnica504efectiva. Pero también tiende a ser caro y no hace mucho para crecer el505grupo de desarrolladores de kernel experimentados. Es posible poner al506día a los desarrolladores internos en el desarrollo de kernel de Linux,507dada la inversión de algún tiempo. Tomarse este tiempo puede dotar a un508empleador de un grupo de desarrolladores que comprendan tanto el kernel509como la empresa, y que también puedan ayudar a educar a otros. A medio510plazo, este es a menudo el enfoque más rentable.511 512Los desarrolladores individuales, a menudo, comprensiblemente, no tienen513un lugar para empezar. Comenzar con un proyecto grande puede ser514intimidante; a menudo uno quiere probar las aguas con algo más pequeño515primero. Este es el punto en el que algunos desarrolladores se lanzan a516la creación de parches para corregir errores ortográficos o problemas517menores de estilo de codificación. Desafortunadamente, dicho parches518crean un nivel de ruido que distrae a la comunidad de desarrollo en su519conjunto, por lo que, cada vez más, se los mira con desprecio. Los nuevos520desarrolladores que deseen presentarse a la comunidad no recibirán la521recepción que desean por estos medios.522 523Andrew Morton da este consejo (traducido) para los aspirantes a524desarrolladores de kernel.525 526::527 528 El proyecto #1 para los principiantes en el kernel seguramente debería529 ser “asegúrese de que el kernel funcione perfectamente en todo momento530 en todas las máquinas que pueda conseguir”. Por lo general, la forma531 de hacer esto es trabajar con otros para arreglar las cosas (¡esto532 puede requerir persistencia!), pero eso está bien, es parte del533 desarrollo del kernel.534 535(https://lwn.net/Articles/283982/)536 537En ausencia de problemas obvios que solucionar, se aconseja a los538desarrolladores que consulten las listas actuales de regresiones y errores539abiertos en general. Nunca faltan problemas que necesitan solución; al540abordar estos problemas, los desarrolladores ganarán experiencia con el541proceso mientras, al mismo tiempo, se ganarán el respeto del resto de la542comunidad de desarrollo.543