En caso de que tengamos varias personas trabajando sobre el mismo repositorio yo creo que es importante definir un poco los procesos para contribuir al repositorio.
Las ramas dev y master
De momento, tenemos dos ramas importantes dev y master. Las dos ramas en cualquier momento deben poder compilar y producir sus builds correspondientes. En la rama master podemos encontrar código listo para producción, por lo general deben ir con tags y firmados. En la rama dev hay código que todavía no está listo para producción. Al menos así es como generalmente me ha tocado trabajar en el pasado. A veces la gente pone todo en master y nada más usa tags para marcar el lanzamiento de una nueva versión.
Lo ideal sería que para poder contribuir al repositorio es necesario crear un fork del repositorio. Las contribuciones deberían ser sobre otras ramas, en pocas palabras no tocar ni dev ni master. La única razón por la cual tendríamos que tocar las ramas sería para hacer los merge y nada más. Solo personas con permiso de escritura al repositorio pueden hacer esto y su rol es básicamente de integrar los contribuciones.
Pull Requests
Los PR (Pull Requests) son el mecanismo usado para explicar la rama que se quiere anexar, su razón de ser, lo que hace, etc. Los mensajes de los commits explican que hace el commit, pero la descripción de los PRs son necesarios para mantener un resumen histórico de las ramas. Los PRs deben ser necesarios incluso para commits triviales simplemente por el hecho de que es más fácil organizarse con los PRs que commits individuales (facilita una conversación mas que nada).
Es preferible también que las ramas de contribución queden abiertas (e.g. no hacer merge sobre dev en los forks). Los integradores hacen los merges sobre estas ramas y de todas formas no querrías hacer merge sobre la rama porque quizás necesites hacer un rebase o agregar nuevos commits al PR. Yo pienso que es más sencillo dejar esa tarea al integrador.
Acuerdo de Licencia de Contribución
No estoy seguro de cual sea el procedimiento adecuado pero yo creo que elhacker.net debería reservar todos los derechos respecto al código publicado en este repositorio. El repositorio y el código fuente no debería ser distribuido. Todos los contribuidores deben ceder sus derechos sobre el código que aportan. Esto yo creo que depende de el-brujo.
No hay muchas personas ahora de momento, así que este issue se siente un poco raro (todos somos integradores de momento).
El repositorio ahora usa una licencia MIT. Contribuciones deberán ser compatibles con esta licencia.
En caso de que tengamos varias personas trabajando sobre el mismo repositorio yo creo que es importante definir un poco los procesos para contribuir al repositorio.
Las ramas
devymasterDe momento, tenemos dos ramas importantes
devymaster. Las dos ramas en cualquier momento deben poder compilar y producir sus builds correspondientes. En la ramamasterpodemos encontrar código listo para producción, por lo general deben ir con tags y firmados. En la ramadevhay código que todavía no está listo para producción. Al menos así es como generalmente me ha tocado trabajar en el pasado. A veces la gente pone todo enmastery nada más usa tags para marcar el lanzamiento de una nueva versión.Lo ideal sería que para poder contribuir al repositorio es necesario crear un fork del repositorio. Las contribuciones deberían ser sobre otras ramas, en pocas palabras no tocar ni
devnimaster. La única razón por la cual tendríamos que tocar las ramas sería para hacer los merge y nada más. Solo personas con permiso de escritura al repositorio pueden hacer esto y su rol es básicamente de integrar los contribuciones.Pull Requests
Los PR (Pull Requests) son el mecanismo usado para explicar la rama que se quiere anexar, su razón de ser, lo que hace, etc. Los mensajes de los commits explican que hace el commit, pero la descripción de los PRs son necesarios para mantener un resumen histórico de las ramas. Los PRs deben ser necesarios incluso para commits triviales simplemente por el hecho de que es más fácil organizarse con los PRs que commits individuales (facilita una conversación mas que nada).
Es preferible también que las ramas de contribución queden abiertas (e.g. no hacer merge sobre
deven los forks). Los integradores hacen los merges sobre estas ramas y de todas formas no querrías hacer merge sobre la rama porque quizás necesites hacer un rebase o agregar nuevos commits al PR. Yo pienso que es más sencillo dejar esa tarea al integrador.Acuerdo de Licencia de Contribución
No estoy seguro de cual sea el procedimiento adecuado pero yo creo queelhacker.netdebería reservar todos los derechos respecto al código publicado en este repositorio. El repositorio y el código fuente no debería ser distribuido. Todos los contribuidores deben ceder sus derechos sobre el código que aportan. Esto yo creo que depende de el-brujo.No hay muchas personas ahora de momento, así que este issue se siente un poco raro (todos somos integradores de momento).
El repositorio ahora usa una licencia MIT. Contribuciones deberán ser compatibles con esta licencia.