@Pecinejo El diálogo es abierto, por eso lo puse aquí y no lo mandé por correo a Ricardo, que ya hemos tenido unos cuantos intercambios con esto del desarrollo de mnm. Mi respuesta adicional a @gallir es la interpretación del mensaje de ESR de pasarse a git [1]. No creo que sea cuestión de modas y shulerias.
Algunos puntos:
- Apenas hay colaboraciones y hay 2 desarrolladores "y pico" << y no sabemos si seguirá igual, por eso pido pasar a algo más social. El debate principal no es solamente técnico (a mi parecer). Y sí, es una petición, no una exigencia.
- Si solo desarrollas tú un 99% del tiempo... << pues habría que ver si con el punto decrece sólo un poco (personalmente tengo mis dudas)
- Git es más pesado/complejo << ¿en qué sentido?
- Para que complicarse la vida si la gran feature tampoco nos aporta nada? << Goto [1]
@gallir@crodas Me parece adecuado todos los puntos, eso dará tiempo a encontrar formas más eficientes de todo, junto con pruebas de concepto independientes. Mi idea inicial siempre ha sido el dejar el control de versiones para sólo eso y el despliegue en algo más sencillo (o especializado) y con menos trabajo para quien le toque hacerlo. Así es como lo llevo en mi trabajo, y sigo aprendiendo en ello.
El WebSVN es bueno, pero si actualmente sólo sirve para mostrar el código igual mejor tirarlo. El primer paso de un mirror en github es avance, y permitirá revisar igualmente la hipótesis de que no hay cambio en la colaboración.
@gallir@gallir@crodas Hay en el mercado de SL varias soluciones para hosting, aunque la más "cómoda" es tercerizarlo. Github* es el defacto. GH ayuda a que puedes integrarlo con otros servicios para pruebas automatizadas (con unit testing, pero eso es otro tema).
Para self-hosting las dos opciones más maduras son GitLab y gitorius. Pero ambas tienen el detalle que son en ruby, y suelen ser bastante pesadas. En Efecto Tequila se tiene GitLab: git.efectotequila.com (nuestro benévolo dictador lo puso en marcha)
En los tres es relativamente sencillo poner los puntos 1 a 3, sobre todo el punto 2 y 3. La belleza de cualquiera de ellos es que se pone en contexto el problema, el código y la colaboración. Hay quieres creen que gitolite es suficiente, pero hasta donde sé no tiene interface web. Redis? Hmmmm no, gracias*.
Sobre el punto 4, es donde hay más trabajo de inicio, aunque igual es más cuestiones de logística lo que se necesitará*.
1.- Estoy segurísimo (sin datos) que los pocos colaboradores que se tienen en mnm es el mismo caso que muchos de los desarrollos de SL y que probablemente no cambiará mucho se pase a DVCs o no. ¿Se podría probar esa hipótesis?
2.- Con "abierta" me refiero a que no se tenga que estar suscrito al svn como (creo) funciona ahora o enviando parches*. Se puede usar "Integration Manager Workflow" o "Dictator and Lieutenants Workflow" [1], para seguir con inspección y arreglo que requieres.
3.- No lo pongo en duda.
4.- No es ningún problema, cuesta un poco de trabajo, sí. De hecho me estoy ofreciendo a ello.
5.- Tampoco lo puse en duda. (¿o si?)
Es necesario evaluar si da más problemas que soluciones. Pro: Facilita colaboración, Pegas: Requiere administrar más.
El punto 1, mi preferencia seguiría en desarrollar poco un paso de deployment/test más en forma, pero para ello sería bueno primero terminar con el tema de colaboración distribuida.
En el punto 2, ya lo vivimos como lo que pasó con los parches que te envié (de los archivos de python), resulta más y más difícil integrarlo con el ritmo que llevan vía svn. La colaboración distribuida es más anárquica en cierto modo, pero vence en conveniencia cuando hay cosas y temas muy sencillos que se pueden aislar por medio de ramas. Eso sin tomar en cuenta lo que menciona ESR sobre la barrera de los nuevos colaborades y las tecnologías que están siendo "vencidas"[1]. Git/hq es un "mal necesario" a favor de la sociabilidad.
Abogo más por una colaboración más abierta (y caótica), aunque sin duda requerirá un(os) paso(s) extra (automatizable, según mi experiencia).
@gallir@crodas Ya lo entiendo mejor, pero a mi parecer se tienen dos temas:
1.- La convenincia de usar el control de versiones como pasarela para deployment/test,
2.- La inconveniencia de la colaboración de terceros en la programación
La idea que propongo sigue siendo la misma, el "Blessed Repository" (BR), serviría igual como viene funcionando svn.meneame.net, pero a diferencia de éste, el control podría llegar a nivel branches: NFS/dev estaría ligado a BR->dev y NFS/www a BR->master. Cada uno de los directorios de NFS puede ser por medio de un clon del BR: cada clon hace un `git pull` cada que lo necesite ya sea con un script, con un hook de git o manualmente o por medio de cron (posibilidades hay muchas).
Si se decidiera lo faltante sería ver si se quiere usar un host de terceros o un hosting local. De ello dependería las siguientes etapas se sincronización de los repo publicos con el BR.
En él, el repositorio "sacred", es decir, el ofical de mnm tendría el control total de qué se modifica en ello, cada colaborador creará su repositorio y enviaría cambios (vía pull requests) basándose en issues públicos, o que se va encontrando uno paso a paso.
A mi parecer este modelo aplica para cualquier DVCS.
*Básicamente no entiendo para o por qué no tener toda la historia.
@cacotos quizás sí, quizás no, podrías estar cayendo en la comidad del prejuicio; puede que estaba distraido, demasiada confianza en su memoria, etc, etc.
@cacotos en mi caso le daba la respuesta correcta, y en la mala nota le presentaba la evidencia de ello (en privado, claroestá), con eso gané la enemistad de 3 profesores, y mejor aún, la amistad de otros 2 que ahora son unos colegas bastante entrañables y solidarios.
No importa cuándo leas esto.
Algunos puntos:
- Apenas hay colaboraciones y hay 2 desarrolladores "y pico" << y no sabemos si seguirá igual, por eso pido pasar a algo más social. El debate principal no es solamente técnico (a mi parecer). Y sí, es una petición, no una exigencia.
- Si solo desarrollas tú un 99% del tiempo... << pues habría que ver si con el punto decrece sólo un poco (personalmente tengo mis dudas)
- Git es más pesado/complejo << ¿en qué sentido?
- Para que complicarse la vida si la gran feature tampoco nos aporta nada? << Goto [1]
[1] lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html
El WebSVN es bueno, pero si actualmente sólo sirve para mostrar el código igual mejor tirarlo. El primer paso de un mirror en github es avance, y permitirá revisar igualmente la hipótesis de que no hay cambio en la colaboración.
Para self-hosting las dos opciones más maduras son GitLab y gitorius. Pero ambas tienen el detalle que son en ruby, y suelen ser bastante pesadas. En Efecto Tequila se tiene GitLab: git.efectotequila.com (nuestro benévolo dictador lo puso en marcha)
En los tres es relativamente sencillo poner los puntos 1 a 3, sobre todo el punto 2 y 3. La belleza de cualquiera de ellos es que se pone en contexto el problema, el código y la colaboración. Hay quieres creen que gitolite es suficiente, pero hasta donde sé no tiene interface web. Redis? Hmmmm no, gracias*.
Sobre el punto 4, es donde hay más trabajo de inicio, aunque igual es más cuestiones de logística lo que se necesitará*.
* a mi parecer
1.- Estoy segurísimo (sin datos) que los pocos colaboradores que se tienen en mnm es el mismo caso que muchos de los desarrollos de SL y que probablemente no cambiará mucho se pase a DVCs o no. ¿Se podría probar esa hipótesis?
2.- Con "abierta" me refiero a que no se tenga que estar suscrito al svn como (creo) funciona ahora o enviando parches*. Se puede usar "Integration Manager Workflow" o "Dictator and Lieutenants Workflow" [1], para seguir con inspección y arreglo que requieres.
3.- No lo pongo en duda.
4.- No es ningún problema, cuesta un poco de trabajo, sí. De hecho me estoy ofreciendo a ello.
5.- Tampoco lo puse en duda. (¿o si?)
Es necesario evaluar si da más problemas que soluciones. Pro: Facilita colaboración, Pegas: Requiere administrar más.
[1] www.git-scm.com/about/distributed
* ¿Cuántos "nuevos" saben hacer un patch? Es bien cómodo los pull-request, la verdá.
El punto 1, mi preferencia seguiría en desarrollar poco un paso de deployment/test más en forma, pero para ello sería bueno primero terminar con el tema de colaboración distribuida.
En el punto 2, ya lo vivimos como lo que pasó con los parches que te envié (de los archivos de python), resulta más y más difícil integrarlo con el ritmo que llevan vía svn. La colaboración distribuida es más anárquica en cierto modo, pero vence en conveniencia cuando hay cosas y temas muy sencillos que se pueden aislar por medio de ramas. Eso sin tomar en cuenta lo que menciona ESR sobre la barrera de los nuevos colaborades y las tecnologías que están siendo "vencidas"[1]. Git/hq es un "mal necesario" a favor de la sociabilidad.
Abogo más por una colaboración más abierta (y caótica), aunque sin duda requerirá un(os) paso(s) extra (automatizable, según mi experiencia).
[1]http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html
1.- La convenincia de usar el control de versiones como pasarela para deployment/test,
2.- La inconveniencia de la colaboración de terceros en la programación
La idea que propongo sigue siendo la misma, el "Blessed Repository" (BR), serviría igual como viene funcionando svn.meneame.net, pero a diferencia de éste, el control podría llegar a nivel branches: NFS/dev estaría ligado a BR->dev y NFS/www a BR->master. Cada uno de los directorios de NFS puede ser por medio de un clon del BR: cada clon hace un `git pull` cada que lo necesite ya sea con un script, con un hook de git o manualmente o por medio de cron (posibilidades hay muchas).
Si se decidiera lo faltante sería ver si se quiere usar un host de terceros o un hosting local. De ello dependería las siguientes etapas se sincronización de los repo publicos con el BR.
Continúa...
@crodas Ahí estoy de acuerdo con @gallir
www.atlassian.com/git/workflows#!workflow-forking
En él, el repositorio "sacred", es decir, el ofical de mnm tendría el control total de qué se modifica en ello, cada colaborador creará su repositorio y enviaría cambios (vía pull requests) basándose en issues públicos, o que se va encontrando uno paso a paso.
A mi parecer este modelo aplica para cualquier DVCS.
*Básicamente no entiendo para o por qué no tener toda la historia.
--- Scaling Mercurial at Facebook ---
code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
cc. @gallir que espero pronto pase mnm a alguno de ellos (el que sea
[1] twitter.com/gvanrossum/status/420674884318941185
En tu caso con una compilación de imdb basta.
Podrías contrastarlo con el de estos bro's:
--- The Query of Despair ---
thedailywtf.com/Articles/The-Query-of-Despair.aspx
--- Escaping legacy IT systems ---
web.mit.edu/newsoffice/2011/legacy-it-systems-0920.html
Mando una nota de física (Einstein, el Universo y esas cosas) y nada: menea.me/t5tx
Ahora si empiezo a creer que en meneame hay mafias
teq.mx/cJ0
Y de repente recordé que eso mismo dijo @gallir hace un buen rato en su tuiter...
I N C E P T I O N
Edit: Más información sobre los cibernoides: youtu.be/RrdcQNVJn2Y
--- Spanish researchers campaign to change science law --
www.nature.com/news/2011/110304/full/news.2011.136.html
theoatmeal.com/blog/digg_tab
Sugiero que se implemente algo igual pero para la Pizarra de Yuri, no?