Roban mi primera contribución al kernel

• El autor estaba lidiando con un problema de depuración en un proyecto que incluía gdbserver y una aplicación multihilo ejecutándose en la arquitectura PowerPC32.
• El problema era que se perdía la conexión con gdbserver, por lo que ya no podía controlar la sesión de depuración.
• Tras investigar y analizar el caso, el autor encontró un hilo de correos que señalaba el commit exacto que causó el problema.
• El autor pasó 3-4 días leyendo las descripciones de commits relacionadas con la arquitectura PowerPC y los cambios alrededor de task_struct, mientras intentaba averiguar si el problema se había resuelto en versiones posteriores del kernel.
• El autor usó varias herramientas y técnicas, como mover thread_struct, inspeccionar el layout de task_struct con pahole y usar ftrace para determinar cuándo se planificaban los hilos del proceso depurado.
• El autor descubrió que el problema podía ser de corrupción de memoria, ya que el hilo bloqueado solo se planificaba una vez, a diferencia de los demás.
• El autor usó breakpoints de hardware en Linux e implementó un módulo del kernel de Linux para colocar un breakpoint de hardware en el campo __state y averiguar quién escribía en él.
• El autor descubrió que el problema era un desbordamiento de búfer en ptrace_put_fpr (usado por la API POKEUSER) que sobrescribía campos críticos de task_struct, como __state.
• Como este problema podía derivar en un issue de seguridad, el autor envió un parche al equipo de seguridad del kernel de Linux ([e-mail]) para solucionarlo.
• En lugar de aceptar el parche del autor, el mantenedor de PowerPC, Michael Ellerman, implementó su propia versión del arreglo.
• El autor sintió que su trabajo no fue reconocido correctamente, se sintió menospreciado y enojado. Solo recibió la etiqueta Reported-by.
• La primera contribución del autor al kernel fue una experiencia llena de frustración y desaliento, marcada por conversaciones con personas que no parecían considerar importante dar el reconocimiento adecuado al trabajo ajeno.

[GN⁺]

Opiniones en Hacker News

• Artículo sobre una situación en la que el parche del colaborador no fue aceptado por completo, pero el mantenedor usó la idea para resolver un problema de seguridad
• Algunos comentarios dicen que, aunque no se haya aceptado el parche completo, el mantenedor debió dar crédito al colaborador
• Otros sostienen que el parche del mantenedor es mejor y más eficiente, pero que aun así hace falta reconocer que el colaborador identificó el problema y propuso una solución
• Algunos comentarios enfatizan la importancia de dar crédito al colaborador, junto con la idea de que el kernel de Linux no es una recompensa y que el mantenedor tiene derecho a elegir la mejor solución
• Se menciona la etiqueta "Suggested-by" de la documentación del kernel como una forma de dar crédito a quien propuso la idea del parche
• Algunos comentarios dicen que esto es una parte común de contribuir al kernel y que el objetivo principal es corregir errores, no recibir crédito
• Comentarios que comparten experiencias de ver ignoradas o no aceptadas por completo sus contribuciones en proyectos de código abierto, lo que puede desalentar aportes futuros
• Comentario que compara el parche del colaborador con el del mantenedor, señala las diferencias y sugiere que se debió dar crédito al autor original
• También se toca la discusión sobre la importancia de tratar las contribuciones de miembros más junior del equipo de una manera que fomente el aprendizaje y la mejora
• Comentario que expresa confusión ante las reacciones negativas y sostiene que el reconocimiento importa, y que agregar coautores es un gesto pequeño pero significativo
• La discusión cierra con comentarios sobre la importancia de la diplomacia y de mantener relaciones a largo plazo en los proyectos de código abierto