Modificar una aplicación de código abierto

9

¿Cuál es el flujo de trabajo general cuando quiero agregar una función a una aplicación de código abierto que originalmente no escribí? ¿Cómo llego a conocer el código? ¿Cómo encuentro el lugar que necesita ser cambiado o agregado? ¿Cómo realizo el cambio sin romper nada más? ¿Cómo pruebo que todo sigue funcionando?
¿Cuáles son las pautas generales para tal proyecto?

open-source Dani
fuente
2
También debe enviar sus cambios al proyecto, generalmente como un parche, para que otros puedan beneficiarse.

Respuestas:

6

Hay algún protocolo, todo el mundo lo desea más o menos con el tiempo, pero aquí está, desenrollado.

  • Descarga la fuente distribuida.

  • Empiezas a navegar un poco por el código

    • Si es un programa compilado, ahora aprenderá cómo compilarlo.
    • Si no lo compila, debe informar al autor / lista de correo y preguntar cómo llegar.

  • Si realmente no entiendes nada sobre el código ...

    • Bueno, no, no les preguntas cerca.
    • Dejas eso, ya que probablemente no estés a la altura y no puedas ser de ninguna ayuda real.
    • Envía una función si el autor (es) acepta solicitudes de funciones.

  • Más

    • Encuentra el lugar que desea cambiar.

    • Si se pregunta acerca de algunos detalles menores, pregunte al autor / lista de correo y explique sus intenciones.

    • Cd al directorio principal de la distribución (el principal que sale de la descompresión / descompresión)

    • usted diff -ur . > mypatch.path

    • Envías mypatch.patchal autor explicando lo que hiciste, por qué lo hiciste y (como ya estás allí) declaras claramente que renuncias a los derechos sobre el parche.

  • si a los autores no les gusta tu contribución

    • verifica si hay una forma de liberar su modificación como un complemento de algún tipo

      • en ese caso, ahora estás en camino de convertirte en un complemento de mantenimiento .

    • más

      • llamas sobre la situación en tu blog y lanzas el parche allí, puedes descargarlo gratis y probar con tu explicación y tus comentarios,

      • Usted persigue de vez en cuando el sistema de errores / lista de correo tratando de comprar soporte para su parche. Evita ser prohibido.

    • en ninguno de estos casos, bifurca el código , ya que es un proceso muy agotador y poco gratificante que difícilmente podrá seguir con el tiempo: eso dejará a los usuarios tristes y confundidos. Las bifurcaciones realmente solo sucederán cuando una gran corporación esté tratando de intimidar sus decisiones sobre una pieza de OSS .

  • más

    • usted recibe más instrucciones de ese autor (es)

En el lado: hay una alternativa reciente al diff -ur .parche y es la forma github .

  • Usted "bifurca" su código en github bajo su nombre
    (ahora tiene una copia de su código en su cuenta)
  • conecta tu git a esa copia personal tuya,
  • haga sus modificaciones al respecto, verifíquelas,

  • y dígale a los autores principales que miren su proyecto github.

  • Si les gusta, se sincronizarán .

  • De lo contrario, puede vincular su "gitfork" en su blog.
ZJR
fuente
Todo bien hasta que sugieras que el OP critica a los autores del producto por no adoptar el nuevo parche de funciones, no está claro si se suponía que era divertido o serio, de cualquier manera, es una forma MUY mala llorar efectivamente como un niño pequeño en todo el mundo porque a un equipo de producto no le gusta / quiere su nuevo parche de funciones. Por supuesto, publíquelo pero siempre sea magnánimo si no fue aceptado, independientemente de lo ilógica que parezca ser la decisión. -1 - Para tu información, felizmente revertiré mi voto, si eliminas eso.
ocodo
La aplicación que quiero cambiar está siguiendo un estándar estricto que con mis cambios romperá el estándar. Creo que ni siquiera estoy en posición de pedir que me apliquen el parche.
Dani
@Slomojo OSS está lleno de personas inmaduras, y ese tipo de cosas suceden todo el tiempo, todos deberían estar preparados para trabajar como una mula y luego ser rechazados sobre la base de que a veces son sólidos y otras son discutibles . Y luego, al menos, siempre tienes la oportunidad de despotricar al respecto y encontrar personas que sientan que quizás tengas razón. Ahora, bifurcando por despecho , ese sería el paso equivocado y muy infantil.
ZJR
@Dani lol, realmente tendrás que compartir un parche y despotricar al respecto . Evite bifurcar, ya que consumirá su vida, se siente como refactorizar continuamente sin un cheque de pago. ... de todos modos, consulte con la lista de correo y el sistema de informe de errores si hay uno, para ver si alguien estaría interesado en ese tipo de extensión, tal vez no esté solo. Y lo mejor sería que tenían alguna API para ampliar o un complemento para conectar sus cambios. Esa es siempre la mejor opción en tales casos: mantener un complemento . ... editará eso.
ZJR
2
Si hay casos de prueba automatizados, ejecútelos antes de enviar el parche.
enone
0

Típicamente.

Si se tratara de un proyecto de sistema operativo aleatorio, lo más probable es que solucione errores menores aquí y allá.

Eventualmente enviaría un montón de cambios, como un "parche".

Por lo general, obtendría derechos de compromiso si sus cosas son buenas.

Estoy hablando en general y lo más vago e inespecífico posible debido a la pregunta

MattyD
fuente