Lines Matching +full:make +full:- +full:git +full:- +full:archive
1 .. include:: ../disclaimer-sp.rst
21 ------------
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]
63 ------------------
73 https://www.gnu.org/licenses/gpl-faq.html
76 --------------
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>`
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>`
143 :ref:`Documentation/process/management-style.rst <managementstyle>`
151 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
156 :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
161 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
173 make pdfdocs
174 make htmldocs
182 make latexdocs
183 make epubdocs
186 ---------------------------------------------
224 es el proyecto Linux Cross-Reference, que es capaz de presentar el código
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
253 de enviar grandes cambios es usando git (la herramienta de
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
262 nuevo después de -rc1 porque no hay riesgo de causar regresiones con
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
267 - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
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
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
313 La mayoría de estos repositorios son árboles git, pero también hay otros
316 MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/.
329 linux-next, para integración y testing
337 https://git.kernel.org/pub/scm/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
353 ------------------------------
374 -----------------
387 https://lore.kernel.org/linux-kernel/
423 formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
435 ----------------------------
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
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."
520 ---------------------
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
605 ----------
617 Maintainer: Greg Kroah-Hartman <greg@kroah.com>