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 6Directrices para Investigadores 7++++++++++++++++++++++++++++++++ 8 9La comunidad del kernel de Linux da la bienvenida a la investigación 10transparente sobre el kernel de Linux, las actividades involucradas 11en su producción, otros subproductos de su desarrollo. Linux se 12beneficia mucho de este tipo de investigación, y la mayoría de los 13aspectos de Linux son impulsados por investigación en una forma u otra. 14 15La comunidad agradece mucho si los investigadores pueden compartir 16los hallazgos preliminares antes de hacer públicos sus resultados, 17especialmente si tal investigación involucra seguridad. Involucrarse 18temprano ayuda a mejorar la calidad de investigación y la capacidad 19de Linux para mejorar a partir de ella. En cualquier caso, se recomienda 20compartir copias de acceso abierto de la investigación publicada con 21la comunidad. 22 23Este documento busca clarificar lo que la comunidad del kernel de Linux 24considera practicas aceptables y no aceptables al llevar a cabo 25investigación de este tipo. Por lo menos, dicha investigación y 26actividades afines deben seguir las reglas estándar de ética de la 27investigación. Para más información sobre la ética de la investigación 28en general, ética en la tecnología y la investigación de las comunidades 29de 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 36La comunidad del kernel de Linux espera que todos los que interactúan con 37el proyecto están participando en buena fe para mejorar Linux. La 38investigación sobre cualquier artefacto disponible públicamente (incluido, 39pero no limitado a código fuente) producido por la comunidad del kernel 40de Linux es bienvenida, aunque la investigación sobre los desarrolladores 41debe ser claramente opcional. 42 43La investigación pasiva que se basa completamente en fuentes disponibles 44públicamente, incluidas las publicaciones en listas de correo públicas y 45las contribuciones a los repositorios públicos, es claramente permitida. 46Aunque, como con cualquier investigación, todavía se debe seguir la ética 47estándar. 48 49La investigación activa sobre el comportamiento de los desarrolladores, 50sin embargo, debe hacerse con el acuerdo explícito y la divulgación 51completa a los desarrolladores individuales involucrados. No se puede 52interactuar / experimentar con los desarrolladores sin consentimiento; 53esto también es ética de investigación estándar. 54 55Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar 56con ellos, pero ya han dado su consentimiento para recibir contribuciones 57en buena fe. No se ha dado consentimiento para enviar parches intencionalmente 58defectuosos / vulnerables o contribuir con la información engañosa a las 59discusiones. Dicha comunicación puede ser perjudicial al desarrollador (por 60ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el 61proyecto al erosionar la confianza de toda la comunidad de desarrolladores en 62el colaborador (y la organización del colaborador en conjunto), socavando 63los esfuerzos para proporcionar reacciones constructivas a los colaboradores 64y poniendo a los usuarios finales en riesgo de fallas de software. 65 66La participación en el desarrollo de Linux en sí mismo por parte de 67investigadores, como con cualquiera, es bienvenida y alentada. La 68investigación del código de Linux es una práctica común, especialmente 69cuando se trata de desarrollar o ejecutar herramientas de análisis que 70producen resultados procesables. 71 72Cuando se interactúa con la comunidad de desarrolladores, enviar un 73parche ha sido tradicionalmente la mejor manera para hacer un impacto. 74Linux ya tiene muchos errores conocidos – lo que es mucho más útil es 75tener soluciones verificadas. Antes de contribuir, lea cuidadosamente 76la 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 83Entonces envíe un parche (incluyendo un registro de confirmación con 84todos los detalles enumerados abajo) y haga un seguimiento de cualquier 85comentario 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 103Por 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 136Si usted es un colaborador por primera vez, se recomienda que el parche en 137si sea examinado por otros en privado antes de ser publicado en listas 138públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches 139necesitan una revisión interna más cuidadosa.) Se espera que estas personas 140tengan su etiqueta “Reviewed-by” incluida en el parche resultante. Encontrar 141otro desarrollador con conocimiento de las contribuciones a Linux, especialmente 142dentro de su propia organización, y tener su ayuda con las revisiones antes de 143enviarlas a las listas de correo publico tiende a mejorar significativamente la 144calidad de los parches resultantes, y reduce así la carga de otros desarrolladores. 145 146Si no se puede encontrar a nadie para revisar internamente los parches y necesita 147ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada 148con este documento y las expectativas de la comunidad de desarrolladores, por 149favor contacte con la lista de correo privada Technical Advisory Board: 150<tech-board@groups.linuxfoundation.org>. 151