¿Parchar el software de código abierto cuando la actualización no es una opción?

13

Hace poco me encontré con un error bastante molesto (confirmado) en un paquete de software de código abierto que he integrado en mi aplicación. Según el rastreador de problemas públicos, este error se resolvió en la última versión del software.

Ocasionalmente NECESITA esa corrección de errores para evitar un refactor costoso de un módulo en particular, sin embargo, por razones técnicas y / o políticas, no podrá actualizar a la última versión.

Al inspeccionar los cambios de código realizados, la solución me parece lo suficientemente simple, por lo que creo que una opción viable sería parchear el código yo mismo y volver a compilar mi versión actual aprobada del software. una mala idea ya que es arriesgado y presenta una complejidad problemática.

En su opinión, porque nosotros hicimos este cambio de código únicamente para nuestro uso, debe ser parte de nuestro código base, lo que significa que en lugar de presentar el software de código abierto como una dependencia de terceros, debemos introducirlo como un nuevo proyectar e incorporar su compilación automatizada en nuestro proceso de compilación.

Para mí, creo que esto es erróneo, ya que estaríamos sacando su código del repositorio de control de origen en el nuestro, y perdemos el historial de los cambios de código que vinieron antes de eso. También parece algo demasiado complicado para un cambio de código tan pequeño que se debe hacer.

¿Sería una mala idea hacer lo anterior en este caso? Si es así, ¿cuál es la situación ideal cuando el código abierto necesita cambiar, pero solo para su beneficio exclusivo?

    
pregunta maple_shaft 22.02.2013 - 13:55

4 respuestas

12

Si no puede usar una versión posterior que no tenga el problema que está encontrando, las únicas opciones que tiene son las siguientes:

  • vive con el problema y encuentra una solución
  • bifurque la biblioteca y corríjala en su versión privada (que es lo que efectivamente estaría haciendo)
  • tira la toalla y dile a tus gerentes que el problema es insuperable (lo que sería una mentira, ya que tienes otras dos opciones abiertas para ti).


He estado en su posición, la opción 2 (hacer un tenedor personalizado) es a menudo la solución más sabrosa disponible. Esa es la vida cuando se trata de bibliotecas de código abierto, especialmente las que evolucionan rápidamente y tienen un mal hábito para romper la compatibilidad entre versiones (lo que, según mi experiencia, es la razón más común para tener que hacer cosas como estas). Para más de unas pocas bibliotecas de OSS, me han dirigido a mí y a los equipos de los que he formado parte para mandar envoltorios a cualquiera de ellos y acceder a la funcionalidad de bibliotecas de terceros exclusivamente a través de esos envoltorios. De esa manera, si necesitamos reemplazar una biblioteca de terceros con una versión que es tan diferente que rompería nuestro código, los cambios se limitan al menos a ese contenedor. No es lo más agradable (agrega código, puede agregar complejidad y rendimiento de costos), pero a veces es la única forma de conservar su cordura.

    
respondido por el jwenting 22.02.2013 - 14:31
6

Lo que está a punto de hacer es una mala idea en el caso más común en el que combina el software de terceros y tiene la intención de rastrear sus lanzamientos . Por lo general, las personas hacen eso porque desean una característica en el componente de terceros que los mantenedores no estén dispuestos a implementar o implementar de la forma que usted necesita.

Sin embargo, usted dijo explícitamente que no actualizará el código incluido. Eso te hace efectivamente el mantenedor del componente de terceros. Por lo tanto, si el parcheo es una buena idea o no, solo depende de si usted entiende ese código lo suficientemente bien como para confiar en el efecto deseado. Sus pruebas de integración deberían ser suficientes para verificar que, de hecho, está haciendo lo que usted asume. Por lo tanto, a medida que explica la situación, me parece que sus revisores están equivocados.

    
respondido por el Kilian Foth 22.02.2013 - 14:22
3

Realmente no hay nada malo en hacer eso, siempre y cuando todos puedan soportar los costos, beneficios y riesgos.

  

... la solución parece lo suficientemente simple ... para parchear el código yo mismo

Cuando tienes un trabajo que hacer, perfecto (tener una biblioteca de terceros que es exactamente lo que quieres) es el enemigo de ser lo suficientemente bueno (parchearlo tú mismo), y algunas veces tienes que hacer cosas así. He realizado una serie de proyectos en los que hemos comprado licencias de origen para bibliotecas comerciales, por lo que podríamos solucionar los problemas antes de que el proveedor lo hiciera.

  

... los detractores quieren discutir el caso de que esto es casi siempre   una mala idea ya que es arriesgado y presenta una complejidad problemática.

Es una mala idea si no tienes las habilidades para manejar la disección del código de otra persona, identificar un problema y escribir una solución. Eso es cierto ya sea que el código sea interno o de un tercero; La única diferencia es si se lanzó sobre un cubículo o una pared de un edificio antes de que aterrizara en tu regazo.

Si sus detractores simplemente están ignorando la idea sin sopesar los costos de no hacer este parche, no están haciendo su tarea. Si tiene una gran cantidad de código interno que se ve afectado por el error que su parche solucionaría, tendrá que pasar por él y cambiarlo para que funcione a su alrededor y volver a probar todo para asegurarse de que funciona correctamente. Luego, si alguna vez actualiza el paquete a una versión corregida por un error, es posible que tenga que buscar y eliminar sus soluciones y volver a realizar la prueba. También existen riesgos al hacer eso, como perder un caso que cambió o pruebas insuficientes. Personalmente, si tengo la oportunidad de corregir un error en su origen, preferiría hacerlo allí que perseguir el resto del código con un matamoscas y espero obtener todo.

  

... nosotros hicimos un cambio de código ... debe ser parte de nuestro código base   ... debemos introducirlo como un nuevo proyecto e incorporar su   compilación automatizada en nuestro proceso de compilación.

Si estás haciendo un parche, el parche es parte de tu propio código, lo que significa que debes hacerlo parte de tu proceso. Esto no es diferente a agregar algo que es 100% su código a su sistema. Trate la distribución de terceros como sacrosanta y colóquela en un módulo como si fuera un código fuente. Todos los parches que escriba se almacenan con él en archivos separados y se aplican como parte del proceso de compilación. De esa manera, siempre se pasa de la fuente limpia a la fuente parcheada al producto construido y se puede mostrar exactamente lo que sucede. (Algunas personas desempaquetan, parchean a mano, vuelven a empacar y almacenan eso en el control de versiones. Eso es malo).

  

... estaríamos sacando su código de su repositorio de control de fuente   en el nuestro, y perdemos la historia detrás de cualquier cambio de código ...

Si está tratando la biblioteca de terceros como una dependencia de terceros, para empezar no tiene ese historial y no está perdiendo nada. Si tiene acceso continuo al repositorio de terceros, puede consultar si lo necesita. Los lanzamientos de terceros deben tratarse como burbujas amorfas que usted verifica en su propio sistema sin alteraciones. Si necesita ver los cambios entre la versión que está utilizando y las versiones posteriores, puede hacerlo y, si lo desea, puede presentar parches a la versión anterior que incorporan los cambios que desea.

  

También parece algo demasiado complicado para   un cambio de código tan pequeño que debe hacerse.

Si su proceso de compilación es lo suficientemente sofisticado, agregar esto no debería ser más difícil que agregar su propio código. Hay una pequeña cantidad de trabajo para llegar al punto en que el proceso de desempaquetar / parchar / compilar sea automático, pero una vez que se hace, se hace para siempre. Puede haber un error ahora, pero podría haber veinte en el futuro. Si lo hay, estarás mucho más contento de haber sentado las bases para apoyar todo eso ahora, porque hará que lidiar con los próximos 19 mucho menos trabajo.

    
respondido por el Blrfl 22.02.2013 - 15:00
2

Lo que quieres hacer parece bastante razonable, pero parece que hay razones (¿sólidas?) en el proceso para oponerte. No compararé las soluciones propuestas, pero quizás haya una manera en la que puedas tener tu pastel y comértelo también:

Si el proyecto de código abierto en cuestión lo permite, contribuya su corrección de fallos en su repositorio. Es decir, si está utilizando la versión 1.5.2 y la versión estable actual es 1.6.1, contribuya con un parche a 1.5.2. Si se adopta, puede obtener la fuente fija directamente desde el repositorio (quizás como la versión 1.5.3) y hacer que todos estén contentos.

En otras palabras: parche para todos los demás que también se encuentren en su situación. Por supuesto, esto solo es posible si el proyecto admite (o al menos permite) actualizaciones a las versiones publicadas. Pero esa es ciertamente una práctica bastante común en estos días.

    
respondido por el alexis 22.02.2013 - 17:28

Lea otras preguntas en las etiquetas