Lines Matching +full:un +full:-
1 .. include:: ./disclaimer-sp.rst
21 ------------
22 ¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
23 kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
31 dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
34 desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
38 - "The C Programming Language" de Kernighan e Ritchie [Prentice Hall]
39 - "Practical C Programming" de Steve Oualline [O'Reilly]
40 - "C: A Reference Manual" de Harbison and Steele [Prentice Hall]
44 no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
54 desarrollo existente. Es un grupo diverso de personas, con altos estándares
57 para un equipo tan grande y geográficamente disperso. Trate de aprender
63 ------------------
67 sobre licencias, contacte a un abogado, no pregunte en listas de discusión
73 https://www.gnu.org/licenses/gpl-faq.html
76 --------------
81 cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
83 información o un parche en las páginas del manual que expliquen el cambio
84 a mtk.manpages@gmail.com, y CC la lista linux-api@vger.kernel.org.
89 :ref:`Documentation/admin-guide/README.rst <readme>`
99 :ref:`Documentation/process/coding-style.rst <codingstyle>`
106 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
107 Este archivo describe en gran detalle cómo crear con éxito y enviar un
110 - Contenidos del correo electrónico (email)
111 - Formato del email
112 - A quien se debe enviar
123 https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
125 :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
129 - Capas intermedias del subsistema (por compatibilidad?)
130 - Portabilidad de drivers entre sistemas operativos
131 - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o
138 :ref:`Documentation/process/security-bugs.rst <securitybugs>`
139 Si cree que ha encontrado un problema de seguridad en el kernel de
143 :ref:`Documentation/process/management-style.rst <managementstyle>`
151 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
153 del kernel estable, y qué hacer si desea obtener un cambio en una de
156 :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
161 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
162 Una buena introducción que describe exactamente qué es un parche y cómo
167 ReStructuredText markups (ReST), como este. Esto incluye un descripción
185 Convertirse en un/a desarrollador/a de kernel
186 ---------------------------------------------
196 el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
203 un kernel y aplicar un parche.
211 Es un gran lugar para comenzar. Describe una lista de problemas
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
232 ------------------------
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
249 - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
252 han incluido en el linux-next durante unas semanas. La forma preferida
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
261 podría aceptar un controlador (o sistema de archivos) completamente
262 nuevo después de -rc1 porque no hay riesgo de causar regresiones con
265 parches a Linus después de que se lance -rc1, pero los parches tambié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
276 *"Nadie sabe cuándo se publicara un nuevo kernel, pues esto sucede
295 semanas, pero puede ser más largo si no hay problemas apremiantes. Un
296 problema relacionado con la seguridad, en cambio, puede causar un
299 El archivo :ref:`Documentación/proceso/stable-kernel-rules.rst <stable_kernel_rules>`
305 Los maintainers de los diversos subsistemas del kernel --- y también muchos
306 desarrolladores de subsistemas del kernel --- exponen su estado actual de
309 desarrollo es rápido, se le puede pedir a un desarrollador que base sus
318 Antes de que un parche propuesto se incluya con dicho árbol de subsistemas,
323 comentario sobre un parche o revisiones a él, y los maintainers pueden
329 linux-next, para integración y testing
334 un repositorio especial de pruebas en el que se encuentran casi todos los
337 https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
339 De esta manera, linux-next ofrece una perspectiva resumida de lo que se
342 linux-next en ejecución.
345 -------------
347 El archivo 'Documentación/admin-guide/reporting-issues.rst' en el
348 directorio principal del kernel describe cómo informar un posible bug del
353 ------------------------------
363 Para trabajar en informes de errores ya reportados, busque un subsistema
366 vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
369 errores; solo un puñado de subsistemas del kernel lo emplean activamente
374 -----------------
381 http://vger.kernel.org/vger-lists.html#linux-kernel
384 distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por
390 tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas
401 http://vger.kernel.org/vger-lists.html
404 Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para
423 formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
426 parche, que funciona sólo de esa manera. Asegúrese de emplear un programa
435 ----------------------------
438 posible. Cuando envíe un parche para su aceptación, se revisará en sus
441 - críticas
442 - comentarios
443 - peticiones de cambios
444 - peticiones de justificaciones
445 - silencio
449 a nivel técnico y re-elaborar sus parches o proporcionar razonamiento claro
456 - esperar que su parche se acepte sin preguntas
457 - actuar de forma defensiva
458 - ignorar comentarios
459 - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes
462 diferentes opiniones sobre lo beneficioso que es un parche. Tiene que ser
474 --------------------------------------------------------------------
482 - "Esto arregla múltiples problemas."
483 - "Esto elimina 2000 lineas de código."
484 - "Aquí hay un parche que explica lo que intento describir."
485 - "Lo he testeado en 5 arquitecturas distintas..."
486 - "Aquí hay una serie de parches menores que..."
487 - "Esto mejora el rendimiento en maquinas típicas..."
491 - "Lo hicimos así en AIX/ptx/Solaris, de modo que debe ser bueno..."
492 - "Llevo haciendo esto 20 años, de modo que..."
493 - "Esto lo necesita mi empresa para ganar dinero"
494 - "Esto es para la linea de nuestros productos Enterprise"
495 - "Aquí esta el documento de 1000 paginas describiendo mi idea"
496 - "Llevo 6 meses trabajando en esto..."
497 - "Aquí esta un parche de 5000 lineas que..."
498 - "He rescrito todo el desastre actual, y aquí esta..."
499 - "Tengo un deadline, y este parche debe aplicarse ahora."
509 el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede
514 sientes cómodas con el inglés. Un buen dominio del idioma puede ser
520 ---------------------
529 ellos, y no simplemente usándolos como un vertedero para su función. Sin
537 exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer
538 con apenas una segunda mirada. Sin embargo, un parche de 500 líneas
544 Es mucho más fácil retirar los parches uno por uno que diseccionar un
552 *"Piense en un maestro que califica la tarea de un estudiante de
555 respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
560 al problema que se está resolviendo. Quieren ver un solución simple y
563 Puede resultar un reto mantener el equilibrio entre presentar una solución
568 está listo para inclusión en un momento dado.
574 ----------------------
581 ---------------------
588 - por qué los cambios son necesarios
589 - el diseño general de su propuesta
590 - detalles de implementación
591 - resultados de sus experimentos
600 llevar años perfeccionar estas prácticas (si es que lo hace). Es un proceso
605 ----------
617 Maintainer: Greg Kroah-Hartman <greg@kroah.com>