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.
@Pecinejo@esparta@crodas Lo decía para quitar completamente el svn de acceso público (y menos trabajo para mantener el demonio y el websvn) y dejar sólo el otro (que llevará unas horas o minutos de retraso).
@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.
Es decir, si encontramos una forma que facilite la colaboración, que nos permita abandonar svn.meneame.net (que vaya mierda de sistema, al estar centralizado e ir por NFS es muy lento y consume recursos) por algo mejor tipo Github pero que no nos complique la gestión del día a día, perfecto. Lo pondremos en marcha.
De hecho comencé a analizarlo para intentar pasar svn.meneame.net a github, y me empecé a encontrar con las pegas de Git (las mismas, aunque a menor escala, que Facebook). Es lo que estoy buscando:
1. Que sea más sencillo y fiable de gestionar branches, por ejemplo.
2. Que facilite la colaboración/envío de parches.
3. Que sea navegable por web.
4. Pero lo fundamental: que al menos mantenga la simplicidad (y velocidad/eficiencia) actual para el test y despliegue.
1. No tenemos problemas de colaboración: en 8 años recibimos muy pocos parches, no hay comunidad de desarrolladores, ni siquiera de los que usan el código de Menéame (normal, son pocos).
2. El código que se ejecuta en Menéame no puede ser resultado de colaboración "abierta", tiene que pasar por mi inspección a fondo y arreglo (que a veces me lleva más trabajo).
3. Es muy sencillo abrir un nuevo directorio o usuario para colaboraciones concretas (como hicimos a veces con @crodas)
4. Nuestra prioridad es gestionar nuestro propio desarrollo (la inmensa mayoría es mío) y el despliegue, con el menor esfuerzo posible, y la menor probabilidad de cometer errores.
5. Es fácil exportar de svn, si hace falta.
Por esto sigo sin ver la ventaja de usar Git ni qué nos soluciona, sin embargo es más complejo de gestionar, nos mete más trabajo y probabilidades de cometer fallos en el día a día.
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.
@crodas@esparta Exportar no es problema, es el uso diario y la felxibilidad. El svn nos es mucho más cómodo. Lo de hacer "mainstream" sólo por tenerlo en GitHub... bueeeeeno
Lo de versiones y caché, hace meses que ha cambiado, por ejemplo:
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"
Gracias a ambos.
O sea, ¿creo otro proyecto y luego lo inserto como submódulo en el subdirectorio? ¿Los commits y push los tengo que hacer por separado?
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.
1. No tocar el sistema actual.
2. Exportar periódicamente a un repositorio git o mercurial.
3. Subirlo a un sistema como Github.
4. Encontrar una forma sencilla de importar parches del otro repositorio al svn.
¿No lo ves posible?
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á.
Es decir, si encontramos una forma que facilite la colaboración, que nos permita abandonar svn.meneame.net (que vaya mierda de sistema, al estar centralizado e ir por NFS es muy lento y consume recursos) por algo mejor tipo Github pero que no nos complique la gestión del día a día, perfecto. Lo pondremos en marcha.
De hecho comencé a analizarlo para intentar pasar svn.meneame.net a github, y me empecé a encontrar con las pegas de Git (las mismas, aunque a menor escala, que Facebook). Es lo que estoy buscando:
1. Que sea más sencillo y fiable de gestionar branches, por ejemplo.
2. Que facilite la colaboración/envío de parches.
3. Que sea navegable por web.
4. Pero lo fundamental: que al menos mantenga la simplicidad (y velocidad/eficiencia) actual para el test y despliegue.
Partes de premisas equivocadas:
1. No tenemos problemas de colaboración: en 8 años recibimos muy pocos parches, no hay comunidad de desarrolladores, ni siquiera de los que usan el código de Menéame (normal, son pocos).
2. El código que se ejecuta en Menéame no puede ser resultado de colaboración "abierta", tiene que pasar por mi inspección a fondo y arreglo (que a veces me lleva más trabajo).
3. Es muy sencillo abrir un nuevo directorio o usuario para colaboraciones concretas (como hicimos a veces con @crodas)
4. Nuestra prioridad es gestionar nuestro propio desarrollo (la inmensa mayoría es mío) y el despliegue, con el menor esfuerzo posible, y la menor probabilidad de cometer errores.
5. Es fácil exportar de svn, si hace falta.
Por esto sigo sin ver la ventaja de usar Git ni qué nos soluciona, sin embargo es más complejo de gestionar, nos mete más trabajo y probabilidades de cometer fallos en el día a día.
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
Lo de versiones y caché, hace meses que ha cambiado, por ejemplo:
<script src="/v_9/js/main.js.php" type="text/javascript" charset="utf-8">