Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
@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.
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas y @Ganon
@alonso Realmente lo que pasó fue que una vez instalé la v4 para trastear, me líe con lo de los subdominios y lo dejé.
Cuando finalmente me decidí a instalar el menéame para ponerlo en funcionamiento "real", busqué "github meneame" en Google y me salió el código de @crodas, que es la v3. Y instalé la v3 sin darme cuenta
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @Ganon y @crodas
@gallir Modifiqué el "bastante mejor" por "sale muy bien parado" ! porque la verdad, es que le da un buen repaso a la competencia y vaya competencia... ni más ni menos que con Fabien Potencier, al que me quito el sombrero por sus impresionantes trabajos (que bien que me han ayudado en varios proyectos).
No sabía que era @crodas ! ea, otro para el saco de amigos.
"El vehículo matrícula "31234 ATUN" está estacionado ilegalmente en una plaza reservada a los admins, se ruega a su propietario, el Sr. @crodas, lo aparque en otro sitio"
@crodas, no, si digo que los clones sí son legales Pero bueno, supongo que dirás que está prohibido menear tus propias meneos con tus clones, cosa que no es legal y está muy mal vista.
Perdona por poner "ein" pero me acabo de despertar y estoy parco en palabras
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
github.com/gallir/Meneame/blob/a7776ed1c294e25779818f58ab246f8418e8e3e
Vamos, que si hay código "subcontratado"
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
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.
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas y @Ganon
Cuando finalmente me decidí a instalar el menéame para ponerlo en funcionamiento "real", busqué "github meneame" en Google y me salió el código de @crodas, que es la v3. Y instalé la v3 sin darme cuenta
@habladorcito @gallir @carme
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @Ganon y @crodas
No sabía que era @crodas
Realmente todo esto viene porque al ver el enlace a la web que te puse se me vino éste otro a la cabeza de inmediato: gallir.wordpress.com/2010/08/11/haanga-plantillas-django-para-php-uber
Grandes que sois, leches !
Como saber sumar y no saber multiplicar.
Perdona por poner "ein" pero me acabo de despertar y estoy parco en palabras