Recientemente 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 ha resuelto en la última versión del software.
Ocasionalmente, NECESITA esa corrección de errores para evitar un costoso refactor 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 parece lo suficientemente simple como para considerar que una opción viable sería parchear el código yo mismo y recompilar mi versión actual aprobada del software, sin embargo, los detractores quieren argumentar que esto es casi siempre una mala idea. en que es arriesgado e introduce una complejidad problemática.
En su opinión, debido a que este cambio de código fue realizado por nosotros únicamente para nuestro uso, debe ser parte de nuestra base de código, lo que significa que, en lugar de introducir el software de código abierto como una dependencia de terceros, debemos presentarlo como un nuevo proyecto e incorporarlo su construcción automatizada en nuestro proceso de construcción.
Para mí, creo que esto es erróneo, ya que estaríamos extrayendo su código de su repositorio de control de origen al nuestro, y perdemos el historial detrás de los cambios de código que ocurrieron antes de eso. Además, parece algo demasiado complicado para un cambio de código tan pequeño que debe hacerse.
¿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 en casa?
fuente
Respuestas:
Si no puede usar una versión posterior que no tenga el problema que está encontrando, las únicas opciones que tiene son
He estado en su posición, la opción 2 (hacer un tenedor personalizado) es a menudo la solución más sabrosa disponible. Así es la vida cuando se trata de bibliotecas de código abierto, especialmente las que evolucionan rápidamente y tienen el mal hábito de romper la compatibilidad hacia atrás entre versiones (que en mi experiencia es la razón más común para tener que hacer cosas como esta).
Para más de unas pocas bibliotecas de OSS, me ha llevado a mí y a los equipos de los que he formado parte para ordenar envoltorios alrededor de todos ellos y acceder a la funcionalidad de bibliotecas de terceros exclusivamente a través de esos envoltorios. De esa forma, si necesitamos reemplazar una biblioteca de terceros con una versión tan diferente que rompería nuestro código, los cambios se limitarán al menos a ese contenedor. No es el mejor (agrega código, puede agregar complejidad y rendimiento de costos), pero a veces es la única forma de mantener la cordura.
fuente
Lo que está a punto de hacer es una mala idea en el caso más común en el que agrupa software de terceros y tiene la intención de rastrear sus lanzamientos . Por lo general, las personas hacen eso porque quieren una característica en el componente de terceros que los encargados del mantenimiento no están dispuestos a implementar, o implementar de la manera que usted necesita.
Sin embargo, usted dijo explícitamente que no actualizará el código incluido. Eso lo convierte efectivamente en el mantenedor del componente de terceros. Por lo tanto, si aplicar parches es una buena idea o no, depende solo de si comprende ese código lo suficientemente bien como para estar seguro del efecto deseado. Sus pruebas de integración deberían ser suficientes para verificar que, de hecho, está haciendo lo que usted supone. Por lo tanto, como cuenta la situación, me parece que sus revisores están equivocados.
fuente
Realmente no hay nada de malo en hacerlo, siempre y cuando todos puedan soportar los costos, beneficios y riesgos.
Cuando tienes un trabajo que hacer, perfecto (tener una biblioteca de terceros que es exactamente lo que quieres) es el enemigo de lo suficientemente bueno (parcharlo tú mismo), y a veces tienes que hacer cosas como esas. He realizado una serie de proyectos en los que hemos comprado licencias de origen para bibliotecas comerciales para que podamos solucionar los problemas antes de que el proveedor llegue a ellos.
Es una mala idea si no tiene las habilidades para manejar la disección del código de otra persona, identificar un problema y escribir una solución. Eso es cierto si el código es interno o de un tercero; la única diferencia es si se arrojó sobre un cubículo o una pared del edificio antes de aterrizar en su regazo.
Si sus detractores simplemente están dejando de lado 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 corregirá su parche, deberá revisarlo y cambiarlo para evitarlo y volver a probar todo para asegurarse de que funciona correctamente. Luego, si alguna vez actualiza el paquete a una versión corregida, puede que tenga que encontrar y eliminar sus soluciones y volver a probar. También existe el riesgo de hacerlo, como perder un caso que cambió o pruebas insuficientes. Personalmente, si tengo la oportunidad de corregir un error en su origen, prefiero hacerlo allí que perseguir el resto del código con un matamoscas y espero obtener todo.
Si está haciendo un parche, el parche es parte de su propio código, lo que significa que debe hacerlo parte de su proceso. Esto no es diferente a agregar algo que sea 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 el código fuente. Cualquier parche que escriba se almacena con él en archivos separados y se aplica como parte del proceso de compilación. De esa manera, siempre pasa de una fuente limpia a una fuente parcheada a un producto construido y puede mostrar exactamente lo que está sucediendo. (Algunas personas desempacan, parchan a mano, vuelven a empacar y almacenan eso en el control de versiones. Eso es malo).
Si está tratando la biblioteca de terceros como una dependencia de terceros, no tiene ese historial para empezar y no está perdiendo nada. Si tiene acceso continuo al repositorio de un tercero, puede consultarlo si lo necesita. Los lanzamientos de terceros deben tratarse como blobs amorfos 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, encontrar parches para la versión anterior que incorporen los cambios que desee.
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 desempaquetado / parche / compilación es 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, será mucho más feliz de haber sentado las bases para apoyar todo eso ahora, porque hará que lidiar con los próximos 19 sea mucho menos trabajo.
fuente
Lo que quiere hacer parece bastante razonable, pero parece que hay (¿sonido?) Razones de proceso para oponerse. No compararé las soluciones propuestas, pero quizás hay una manera de 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 errores portada a 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 (tal vez como la versión 1.5.3) y hacer felices a todos.
En otras palabras: parchealo para todos los demás que también están 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 estándar en estos días.
fuente