¿De quién es la responsabilidad de un parche de corrección de errores?

12

Una situación que ha surgido varias veces en proyectos de código abierto es la siguiente:

  1. Noté un error en nuestra implementación y descubrí un parche rápido. (Por ejemplo, simplemente comentar un código que realmente no necesitamos).
  2. Hago un poco de esfuerzo adicional para descubrir el error real, crear un parche y enviarlo mediante una solicitud de extracción de Git o similar.
  3. Mi solicitud de extracción es rechazada. Quizás el parche era imperfecto (p. Ej., Líneas incluidas que no debería haber), tal vez violaba el estilo de codificación, quizás tenía otras ramificaciones. O tal vez hice algo mal en Git: la solicitud de extracción debería haberse rebasado o algo así. Un mantenedor proporciona comentarios sobre cómo mejorar el parche y solicita que lo vuelva a enviar.

En este punto, estoy confundido acerca de lo lejos que debo proceder. En lo que a mí respecta, no tengo un problema: lo arreglé nuevamente en el paso 1. He informado el problema, incluso he tomado medidas para solucionarlo para otros. Pero no creo que sea "mi" solicitud de extracción, por lo que no creo que la responsabilidad de mejorar el parche me llegue.

Una situación particular que me molesta es después de una discusión acerca de las fallas de mi parche, llegamos a un acuerdo en una lista de correo sobre cuál sería el parche correcto (es decir, cómo debería comportarse, a veces incluyendo cada línea de código explicada) . Entonces, todavía se presume que es mi responsabilidad generar y enviar el parche.

¿Hay una etiqueta estándar en estas situaciones? ¿Cómo se resuelven? ¿Mi reacción es inusual? ¿Hasta dónde se espera que llegue para que se acepte su corrección de errores?

(Tenga en cuenta que cuando digo "proyecto de código abierto", algunos de estos son muy pequeños, pero pueden no ser pasatiempos, simplemente pequeños proyectos de software que son útiles para varias organizaciones, que comprometen recursos de desarrolladores para trabajar en ellos. En caso de que la respuesta obvia es "arreglar el parche y reenviarlo", entiendo que tengo responsabilidades con mi empleador para trabajar en cosas que son beneficiosas para ellos. Pasar el tiempo reparando un error que no nos afecta sería incorrecto ...)

    
pregunta Steve Bennett 17.04.2012 - 16:05

6 respuestas

12

En lo que a mí respecta, si encuentra un error o tiene una solicitud de mejora, no contribuye al proyecto y ha enviado un informe de defectos a través de los canales apropiados, ya ha terminado. En términos de devolver a la comunidad, cualquier persona que esté utilizando un proyecto de código abierto y encuentre un defecto debe informarlo.

Intentar encontrar una solución, diseñarla e implementarla es una ventaja para el proyecto. Si ha hecho esto, puede ser una buena idea enviarlo, ya sea a través de una solicitud de extracción o quizás enviando deltas de archivos al equipo de desarrollo junto con el informe de defectos o la solicitud de mejora para darles algo con qué trabajar. Sin embargo, no están obligados a aceptar su contribución al proyecto.

Para mí, esperar que un usuario contribuya con parches me parece mal. Es bastante fácil participar en una discusión sobre un problema, pero es una inversión de tiempo mucho mayor para encontrar una solución. Ningún proyecto debe esperar que los no contribuyentes se conviertan en colaboradores solo para solucionar un solo problema.

    
respondido por el Thomas Owens 17.04.2012 - 16:27
5

Continúa hasta donde estés dispuesto a soportarlo. Sería bueno arreglar tu parche y compartirlo con el mundo en el troncal principal, pero si el mantenedor no lo hace No lo quiero, encogerse de hombros. Puede publicar en algún lugar su problema y el parche para solucionarlo, de modo que otros en el mismo barco puedan buscar una solución.

Y no estás sin problema. Su parche no estará en la próxima actualización. Tendrá que volver a realizar el envío y esperar que funcione o masajearlo en su lugar cada vez que tome una nueva versión. Por lo tanto, incluirlo en el proyecto principal le ahorrará a usted ya su empresa tiempo a largo plazo.

Es un dolor para ti, pero estás contribuyendo a la comunidad. Ciertamente aprecio todo el trabajo que aportan los colaboradores. No es como un software de calidad, mágicamente, se trata de las masas. Alguien tiene que hacer el trabajo. (Entonces, ¿quién es increíble? Eres increíble). Si no te sientes con ganas de hacerlo, anuncia a la comunidad que, si bien aprecias la discusión de cómo debería ser, simplemente estás demasiado ocupado para hacerlo. Quiero decir, ¿qué van a hacer? ¿Recortar su salario?

    
respondido por el Philip 17.04.2012 - 16:31
4

Hay un principio que hace que la cultura de código abierto sea más fácil de entender: la persona que hace el trabajo decide en qué trabajar. Este es uno de sus atractivos en comparación con los trabajos diurnos de los desarrolladores. Su prioridad # 1 podría ser # 50 en su backlog. Si no arreglas tu solicitud de extracción, es probable que finalmente llegue a la cima y ellos se ocupen de ello. Sin embargo, si se lo facilita, ellos se encargarán de ello ahora.

La otra razón por la que te piden que arregles tu solicitud de extracción es más magnánima. Quieren que obtengas crédito por tu contribución, por pequeña que sea. Si realiza la reparación, su nombre es el que se encuentra en el campo de autor de la confirmación. La mayoría de las personas están lo suficientemente orgullosas de su contribución para querer verla, por lo que el modo de funcionamiento predeterminado de los mantenedores es permitirles.

En lo que respecta a su responsabilidad para con su empleador, si su empresa confía en este código, no le está haciendo ningún daño. Los empleadores conocen el beneficio de que un trabajador se tome el tiempo de afilar sus herramientas.

    
respondido por el Karl Bielefeldt 17.04.2012 - 20:24
2

AFAIK, la forma de código abierto es que la responsabilidad de corregir errores se deja a la persona que se preocupa lo suficiente por el error para manejar la carga y garantizar que se solucione. Dependiendo de las circunstancias, he hecho todo, desde simplemente ignorar un problema hasta luchar (proporcionar parches y argumentar para que sean aceptados) para asegurar que se solucionó.

Todo está bien, simplemente no permita que las personas que gestionan el proyecto esperen algo incorrecto de usted (es decir, déles la esperanza de que solucionen el problema adecuadamente mediante las opciones de discusión y luego no hagan nada). problemas que pueden manejar ellos mismos y tratarán de hacer de usted un colaborador recurrente si pueden.

    
respondido por el AProgrammer 17.04.2012 - 16:40
1

Es posible que el error original solo lo afecte, por lo que le interesa mucho hacer el envío haciendo lo que sea necesario para que su parche cumpla con las normas. De lo contrario, la próxima versión que tire (porque necesita otras correcciones) faltará su corrección.

No desea mantener una lista de parches que necesita aplicar cada vez que saque una nueva copia del proyecto, es demasiado problema. Tómate un poco de tiempo adicional y arréglalo permanentemente para que no tengas que lidiar con eso nuevamente.

    
respondido por el Scott C Wilson 17.04.2012 - 16:40
1

Para un desarrollador de código abierto, hay dos tipos de problemas:

  • (a) problemas sin un parche
  • (b) problemas causados por un parche

Creo que a la mayoría de los desarrolladores / desarrolladores de paquetes de código abierto les ENCANTA la idea de ayudar a que un colaborador que no sea de núcleo se ponga al día con sus parches.

Su objetivo principal, sin embargo, es minimizar el número de problemas de tipo b. Es por eso que la barra está bastante alta.

Algunas personas lo superan. Se convierten en contribuyentes, o incluso en contribuyentes principales. Otros se dan por vencidos. El Open Source tiene cierta naturaleza darwiniana: la supervivencia del más apto.

Le animo a que presione y brille su contribución hasta el punto en que el equipo la acepte. Una vez que hayas hecho algunas contribuciones, confiarán más en ti, pero aún así debes asegurarte de que tus contribuciones sean impecables.

El resultado final lo vale totalmente. Cosas como poder decir "¿Codifico? Sí ... Estás ejecutando algo que escribí, todos los días".

    
respondido por el pbr 18.04.2012 - 03:11

Lea otras preguntas en las etiquetas