Skip to content

Commit 9e6e2ed

Browse files
Avadhut NaikJonathan Corbet
Avadhut Naik
authored and
Jonathan Corbet
committed
docs/sp_SP: Add translation of process/researcher-guidelines
Translate Documentation/process/researcher-guidelines.rst into Spanish Signed-off-by: Avadhut Naik <avadhut.naik@amd.com> Reviewed-By: Carlos Bilbao <carlos.bilbao@amd.com> [jc: removed unneeded label at the top] Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230621171457.443362-2-avadhut.naik@amd.com
1 parent eeedd1b commit 9e6e2ed

2 files changed

Lines changed: 151 additions & 0 deletions

File tree

‎Documentation/translations/sp_SP/process/index.rst‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,3 +20,4 @@
2020
programming-language
2121
deprecated
2222
adding-syscalls
23+
researcher-guidelines

‎Documentation/translations/sp_SP/process/researcher-guidelines.rst‎

Lines changed: 150 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,150 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
3+
:Original: :ref:`Documentation/process/researcher-guidelines.rst`
4+
:Translator: Avadhut Naik <avadhut.naik@amd.com>
5+
6+
Directrices para Investigadores
7+
++++++++++++++++++++++++++++++++
8+
9+
La comunidad del kernel de Linux da la bienvenida a la investigación
10+
transparente sobre el kernel de Linux, las actividades involucradas
11+
en su producción, otros subproductos de su desarrollo. Linux se
12+
beneficia mucho de este tipo de investigación, y la mayoría de los
13+
aspectos de Linux son impulsados por investigación en una forma u otra.
14+
15+
La comunidad agradece mucho si los investigadores pueden compartir
16+
los hallazgos preliminares antes de hacer públicos sus resultados,
17+
especialmente si tal investigación involucra seguridad. Involucrarse
18+
temprano ayuda a mejorar la calidad de investigación y la capacidad
19+
de Linux para mejorar a partir de ella. En cualquier caso, se recomienda
20+
compartir copias de acceso abierto de la investigación publicada con
21+
la comunidad.
22+
23+
Este documento busca clarificar lo que la comunidad del kernel de Linux
24+
considera practicas aceptables y no aceptables al llevar a cabo
25+
investigación de este tipo. Por lo menos, dicha investigación y
26+
actividades afines deben seguir las reglas estándar de ética de la
27+
investigación. Para más información sobre la ética de la investigación
28+
en general, ética en la tecnología y la investigación de las comunidades
29+
de desarrolladores en particular, ver:
30+
31+
32+
* `Historia de la Ética en la Investigación <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
33+
* `Ética de la IEEE <https://www.ieee.org/about/ethics/index.html>`_
34+
* `Perspectivas de Desarrolladores e Investigadores sobre la Ética de los Experimentos en Proyectos de Código Abierto <https://arxiv.org/pdf/2112.13217.pdf>`_
35+
36+
La comunidad del kernel de Linux espera que todos los que interactúan con
37+
el proyecto están participando en buena fe para mejorar Linux. La
38+
investigación sobre cualquier artefacto disponible públicamente (incluido,
39+
pero no limitado a código fuente) producido por la comunidad del kernel
40+
de Linux es bienvenida, aunque la investigación sobre los desarrolladores
41+
debe ser claramente opcional.
42+
43+
La investigación pasiva que se basa completamente en fuentes disponibles
44+
públicamente, incluidas las publicaciones en listas de correo públicas y
45+
las contribuciones a los repositorios públicos, es claramente permitida.
46+
Aunque, como con cualquier investigación, todavía se debe seguir la ética
47+
estándar.
48+
49+
La investigación activa sobre el comportamiento de los desarrolladores,
50+
sin embargo, debe hacerse con el acuerdo explícito y la divulgación
51+
completa a los desarrolladores individuales involucrados. No se puede
52+
interactuar / experimentar con los desarrolladores sin consentimiento;
53+
esto también es ética de investigación estándar.
54+
55+
Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar
56+
con ellos, pero ya han dado su consentimiento para recibir contribuciones
57+
en buena fe. No se ha dado consentimiento para enviar parches intencionalmente
58+
defectuosos / vulnerables o contribuir con la información engañosa a las
59+
discusiones. Dicha comunicación puede ser perjudicial al desarrollador (por
60+
ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el
61+
proyecto al erosionar la confianza de toda la comunidad de desarrolladores en
62+
el colaborador (y la organización del colaborador en conjunto), socavando
63+
los esfuerzos para proporcionar reacciones constructivas a los colaboradores
64+
y poniendo a los usuarios finales en riesgo de fallas de software.
65+
66+
La participación en el desarrollo de Linux en sí mismo por parte de
67+
investigadores, como con cualquiera, es bienvenida y alentada. La
68+
investigación del código de Linux es una práctica común, especialmente
69+
cuando se trata de desarrollar o ejecutar herramientas de análisis que
70+
producen resultados procesables.
71+
72+
Cuando se interactúa con la comunidad de desarrolladores, enviar un
73+
parche ha sido tradicionalmente la mejor manera para hacer un impacto.
74+
Linux ya tiene muchos errores conocidos – lo que es mucho más útil es
75+
tener soluciones verificadas. Antes de contribuir, lea cuidadosamente
76+
la documentación adecuada.
77+
78+
* Documentation/process/development-process.rst
79+
* Documentation/process/submitting-patches.rst
80+
* Documentation/admin-guide/reporting-issues.rst
81+
* Documentation/process/security-bugs.rst
82+
83+
Entonces envíe un parche (incluyendo un registro de confirmación con
84+
todos los detalles enumerados abajo) y haga un seguimiento de cualquier
85+
comentario de otros desarrolladores.
86+
87+
* ¿Cuál es el problema específico que se ha encontrado?
88+
* ¿Como podría llegar al problema en un sistema en ejecución?
89+
* ¿Qué efecto tendría encontrar el problema en el sistema?
90+
* ¿Como se encontró el problema? Incluya específicamente detalles sobre
91+
cualquier prueba, programas de análisis estáticos o dinámicos, y cualquier
92+
otra herramienta o método utilizado para realizar el trabajo.
93+
* ¿En qué versión de Linux se encontró el problema? Se prefiere usar la
94+
versión más reciente o una rama reciente de linux-next (ver
95+
Documentation/process/howto.rst).
96+
* ¿Que se cambió para solucionar el problema y por qué se cree es correcto?
97+
* ¿Como se probó el cambio para la complicación y el tiempo de ejecución?
98+
* ¿Qué confirmación previa corrige este cambio? Esto debería ir en un “Fixes:”
99+
etiqueta como se describe en la documentación.
100+
* ¿Quién más ha revisado este parche? Esto debería ir con la adecuada “Reviewed-by”
101+
etiqueta; Vea abajo.
102+
103+
Por ejemplo (en inglés, pues es en las listas)::
104+
105+
From: Author <author@email>
106+
Subject: [PATCH] drivers/foo_bar: Add missing kfree()
107+
108+
The error path in foo_bar driver does not correctly free the allocated
109+
struct foo_bar_info. This can happen if the attached foo_bar device
110+
rejects the initialization packets sent during foo_bar_probe(). This
111+
would result in a 64 byte slab memory leak once per device attach,
112+
wasting memory resources over time.
113+
114+
This flaw was found using an experimental static analysis tool we are
115+
developing, LeakMagic[1], which reported the following warning when
116+
analyzing the v5.15 kernel release:
117+
118+
path/to/foo_bar.c:187: missing kfree() call?
119+
120+
Add the missing kfree() to the error path. No other references to
121+
this memory exist outside the probe function, so this is the only
122+
place it can be freed.
123+
124+
x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
125+
11.2 show no new warnings, and LeakMagic no longer warns about this
126+
code path. As we don't have a FooBar device to test with, no runtime
127+
testing was able to be performed.
128+
129+
[1] https://url/to/leakmagic/details
130+
131+
Reported-by: Researcher <researcher@email>
132+
Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
133+
Signed-off-by: Author <author@email>
134+
Reviewed-by: Reviewer <reviewer@email>
135+
136+
Si usted es un colaborador por primera vez, se recomienda que el parche en
137+
si sea examinado por otros en privado antes de ser publicado en listas
138+
públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches
139+
necesitan una revisión interna más cuidadosa.) Se espera que estas personas
140+
tengan su etiqueta “Reviewed-by” incluida en el parche resultante. Encontrar
141+
otro desarrollador con conocimiento de las contribuciones a Linux, especialmente
142+
dentro de su propia organización, y tener su ayuda con las revisiones antes de
143+
enviarlas a las listas de correo publico tiende a mejorar significativamente la
144+
calidad de los parches resultantes, y reduce así la carga de otros desarrolladores.
145+
146+
Si no se puede encontrar a nadie para revisar internamente los parches y necesita
147+
ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada
148+
con este documento y las expectativas de la comunidad de desarrolladores, por
149+
favor contacte con la lista de correo privada Technical Advisory Board:
150+
<tech-board@lists.linux-foundation.org>.

0 commit comments

Comments
 (0)