Documentation/translations/sp_SP/process/email-clients.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/process/email-clients.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/sp_SP/process/email-clients.rst- Extension
.rst- Size
- 14423 bytes
- Lines
- 375
- 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.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. include:: ../disclaimer-sp.rst
:Original: :ref:`Documentation/process/email-clients.rst <email_clients>`
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
.. _sp_email_clients:
Información de clientes de correo electrónico para Linux
========================================================
Git
---
A día de hoy, la mayoría de los desarrolladores usan ``git send-email`` en
lugar de los clientes de correo electrónico normales. La página de manual
para esto es bastante buena. En la recepción del correo, los maintainers
usan ``git am`` para aplicar los parches.
Si es usted nuevo en ``git`` entonces envíese su primer parche. Guárdelo
como texto sin formato, incluidos todos los encabezados. Ejecute ``git am raw_email.txt``
y luego revise el registro de cambios con ``git log``. Cuando eso funcione,
envíe el parche a la(s) lista(s) de correo apropiada(s).
Preferencias Generales
----------------------
Los parches para el kernel de Linux se envían por correo electrónico,
preferiblemente como texto en línea en el cuerpo del correo electrónico.
Algunos maintainers aceptan archivos adjuntos, pero entonces los archivos
adjuntos deben tener tipo de contenido ``text/plain``. Sin embargo, los
archivos adjuntos generalmente están mal vistos porque hacen que citar
partes del parche sea más difícil durante el proceso de revisión del
parche.
También se recomienda encarecidamente que utilice texto sin formato en el
cuerpo del correo electrónico, para parches y otros correos electrónicos
por igual. https://useplaintext.email puede ser útil para obtener
información sobre cómo configurar su cliente de correo electrónico
preferido, así como una lista de clientes de correo electrónico
recomendados si aún no tiene una preferencia.
Los clientes de correo electrónico que se utilizan para los parches del
kernel Linux deben enviar el texto del parche intacto. Por ejemplo, no
deben modificar ni eliminar pestañas o espacios, incluso al principio o al
final de las líneas.
No envíe parches con ``format=flowed``. Esto puede causar saltos de línea
no deseados e inesperados.
No deje que su cliente de correo electrónico ajuste automáticamente las
palabras por usted. Esto también puede corromper su parche.
Los clientes de correo electrónico no deben modificar la codificación del
de caracteres del texto. Los parches enviados por correo electrónico deben
estar en codificación ASCII o UTF-8 únicamente. Si configura su cliente de
correo electrónico para enviar correos electrónicos con codificación UTF-8,
evite algunos posibles problemas con los caracteres.
Los clientes de correo electrónico deben generar y mantener los
encabezados "References:" o "In-Reply-To:" para que el hilo de correo no
se rompa.
Copiar y pegar (o cortar y pegar) generalmente no funciona para los
parches, porque las tabulaciones se convierten en espacios. Utilizar
xclipboard, xclip y/o xcutsel puede funcionar, pero es mejor probarlo usted
mismo o simplemente evitar copiar y pegar.
No utilice firmas PGP/GPG en el correo que contiene parches.
Esto rompe muchos scripts que leen y aplican los parches.
(Esto debería ser reparable.)
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.