Documentation/translations/sp_SP/process/7.AdvancedTopics.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/sp_SP/process/7.AdvancedTopics.rst
Extension
.rst
Size
12132 bytes
Lines
215
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. include:: ../disclaimer-sp.rst

:Original: Documentation/process/7.AdvancedTopics.rst
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>

.. _sp_development_advancedtopics:

Temas avanzados
===============

Llegados a este punto, con suerte, tiene una idea de cómo funciona el
proceso de desarrollo. Sin embargo, ¡todavía hay más que aprender! Esta
sección cubrirá varios temas que pueden ser útiles para los desarrolladores
que desean convertirse en una parte regular del proceso de desarrollo del
kernel Linux.

Gestionar parches con git
-------------------------

El uso del control de versiones distribuido para el kernel comenzó a
principios de 2002 cuando Linus comenzó a jugar con la aplicación
propietaria BitKeeper. Aunque BitKeeper fue controvertido, el enfoque de
la gestión de versiones de software que incorporó ciertamente no lo fue.
El control de versiones distribuido permitió una aceleración inmediata
del proyecto de desarrollo del kernel. En los tiempos actuales, existen
varias alternativas gratuitas a BitKeeper. Para bien o para mal, el
proyecto del kernel ha optado por git como su herramienta preferida.

Administrar parches con git puede hacer la vida mucho más fácil para el
desarrollador, especialmente a medida que crece el volumen de esos
parches. Git también tiene sus asperezas y representa ciertos peligros;
es una herramienta joven y poderosa que aún está siendo civilizada por
sus desarrolladores. Este documento no intentará enseñar al lector cómo
usar git; eso sería material suficiente para un documento extenso por
derecho propio. En su lugar, el enfoque aquí será cómo git encaja en el
proceso de desarrollo del kernel en particular. Los desarrolladores que
deseen ponerse al día con git encontrarán más información en:

	https://git-scm.com/

	https://www.kernel.org/pub/software/scm/git/docs/user-manual.html

y en varios tutoriales que se encuentran en la web.

El primer orden del negocio es leer los sitios mencionados anteriormente
y comprender cómo funciona git antes de intentar usarlo para poner
parches a disposición de otros. Un desarrollador que usa git debe ser
capaz de obtener una copia del repositorio mainline, explorar el historial
de revisiones, hacer commits en el árbol, usar ramas, etcétera. También es
útil entender las herramientas de git para rescribir la historia (como
rebase). Git viene con su propia terminología y conceptos; un nuevo
usuario de git debe conocer las referencias, las ramas remotas, el índice,
las fusiones fast-forward, los pushes y pulls, las cabezas separadas,
etcétera. Todo puede ser un poco intimidante al principio, pero los
conceptos no son tan difíciles de entender con un poco de estudio.

Usar git para generar parches para enviarlos por correo electrónico puede
ser un buen ejercicio mientras te pones al día.

Cuando esté listo para comenzar a publicar árboles de git para que otros
los vean, necesitará por supuesto, un servidor del que se pueda extraer.
Configurar un servidor de este tipo con git-daemon es relativamente
sencillo si tiene un sistema accesible a Internet. De lo contrario, los
sitios de alojamiento público y gratuitos (GitHub, por ejemplo) están
comenzando a aparecer en la red. Los desarrolladores establecidos pueden
obtener una cuenta en kernel.org, pero no son fáciles de conseguir; ver
https://kernel.org/faq/ para más información.

El flujo de trabajo normal de git implica el uso de muchas ramas. Cada
línea de desarrollo puede separarse en una “rama temática” separada y

Annotation

Implementation Notes