Alojamiento Del Proyecto

A ver… he estado mirando sitios donde alojar el
proyecto, y tenemos varias opciones.

1. Sourceforge. Pro: es tocha, tiene miles de mirrors.

Contra: los foros de cada proyecto dan asco, no tiene
wiki, es CVS de nabo.

2. Google code. (http://code.google.com/hosting/)
PRO: tiene wiki, no obliga a tener cuenta gmail,
alojamiento subversion (podríamos tener git en algún
otro lado tipo repo.or.cz/ ).
Contra: odio a google (XD), no tienen alojamiento de
git o ningún sistema de versiones distribuido, el wiki
parece un poco nabs, obliga a registrar

3. Launchpad (launchpad.net) PRO: ubuntu lo usa, AWN
se ha mudado de google code a esto, bazaar como
sistema de control de versiones (es distribuido,
multiplataforma, etc etc etc) => en el proyecto puedes
tener varios branches y le sigue la pista a todos, y
además puedes currar desconectado (lo que ES la
ventaja de un sistema de control de versiones
distribuído).
Contra: parece un lío, no veo wiki por ningún lado
(tiene una historia de blueprints que debe ser
parecido, como para especificar features, que puede
estar adecuado o puede ser demasiado inflexible).

4. Keli de alguien. PRO: Instalamos lo que queramos
(mediawiki, subversion, git, lo que sea).
Contra: Hay que hacerlo xD, administrarlo, instalar el
turrón, etc. Lo haría pero no creo que valga la pena
(además en mi casa hay poca cpu para esto, pero hay un
plan B que es alojarlo en físicas donde adri tiene
hueco).

Resumiendo: subversion (conocido, limitado, necesitas
conexión para hacer commits) o algo distribuido (sea
git, svk que es compatible con subversion o bazaar)
(tengo que enterarme bien de cómo se usa, tiene que
ser pino con hacer branches de código tipo
"presentación-tal-día", "feature-uber-broken", etc y
luego pasar código de un branch a otro, mola poder
currar desconectado pero con control de versiones y
luego sincronizar). Opiniones? Votación?

A título personal, yo voy a usar distribuido de todas
formas (git y bazaar pueden sincronizar contra un
server subversion externo pero hacer los commit sin
estar conectado), así que me da un poco igual. En
cuanto me aclare (y decidamos) intentaré escribir unos
tutoriales. Estaría adecuado tener wiki, sin duda,
porque para hacer la documentación es bastante cómodo.

Siento el tochaco en mi línea, le vais a coger pánico
a mis mails XD.

RESPUESTA:

Buenas, a mí me da un poco igual, pero por probar bazaar, yo lo
pondría en launchpad (si no ponen muchas pegas) y si no tienen wiki,
pues lo montamos alguno en casa, o monto uno de estrangis en
delegacion xD

RESPUESTA:

Buenas

A ver, a mí me gustaría usar launchpad, tiene buena pinta, pero siendo sinceros y realistas, cuanto menos tengamos que aprender mejor, porque no nos va a sobrar el tiempo. Es decir, si hay que aprender bazaar, python… además de lo que hay que aprender por cojones, al final estaremos saturados.

Saludos

RESPUESTA:

Fruten por mí… Las opciones parecen google code con
wiki nabo y distribuido externo, o launchpad un poco
más lioso pero con bazaar integrado y wiki externo.

Algunas opciones de wiki externo (con ads, pero es lo
que toca) basadas en mediawiki igual que la wikipedia:

http://bluwiki.com/go/Main_Page
www.wiki-site.com/
scribblewiki.com/ <- mi voto si tiramos de wiki
externo, la url es un poco más fea pero parece que
cargan rapidito y es sitio.scribblewiki.com .

RESPUESTA INUTIL:

a mi me da igual por que como nunca he utilizado ningun control de versiones pues tendria que aprender igual. de todas formas si seguimos a este ritmo nos ventilamos el proyecto en na, ya vereis. me juego un testiculo a q ninguno de los otros grupos va tan avanzado.

RESPUESTA:

Yo voto por Launchpad+wiki tipo scribblewiki.com. Si no pues google code y andando

RESPUESTA:

Yo estoy igual XD

RESPUESTA:

Buenas noches

He actualizado el doc de inotify con python (para poner un poco de C++ y inotify a pelo). Aprovecho para repetir lo que dije antes: me parece una pérdida de tiempo que todos le demos caña a inotify, y que por ejemplo nadie le de caña a tracker/beagle o a otras partes del proyecto, por eso es mejor organizarse ya, partir en grupos o como sea.
Tampoco me parece demasiado acertada la idea de realizar el proyecto en python:

- Porque es un handicap al tiempo de desarrollo
- Porque hay que justificarle a Gervás qué hace indispensable Python frente a C++ (y yo no lo tengo nada claro)
- Porque C++ da problemas, pero son problemas que conocemos. Python dará nuevos y emocionantes problemas (y no tenemos gurús de Python).

Con esto no quiero decir que el interfaz por ejemplo no se haga en Python, ahí sí que veo una ventaja real frente a C++, pero no en el core.

Voy a tratar de instalar Time Vault mañana, así como Tracker, y a ver si esta semana tengo algo de tiempo, aunque entre mi cumpleaños y el CUPCAM hasta el viernes iré a trompicones.

Saludos

RESPUESTA:

y viceversa:
· el handicap va a estar ahí en cualquier caso. Empezar a escribir será más lento, pero vamos a comer python del bueno para el gui de todos modos, y sin gui no tenemos mucho. Y recemos porque la integración con nautilus se pueda hacer en python (debería; habrá que echar un vistazo al fuente de timevault para ver cómo lo hacen, y mirar con cuidado lo de meter-una-barra-de-tiempo que va a ir a la segunda fase me da a mí).
· ¿Qué hace indispensable a C++ frente a python? ¿Que se puede modelar en UML? Podemos restringirnos al subset de python que se parezca a C++ y no creo que perdamos generalidad (nadie habla de usar lambdas, que se puede, o reflection, o cosas raras que conozco solamente de oidas; tampco tenemos por qué reencontrarnos con el dolor con templates e iteratorfests). A título personal, si tuviera que escribir C++ ahora mismo sería casi como empezar de cero para mí, ya que llevo unos añitos sin tocarlo ni de lejos. No sé si seré el único en la situación; me inclino a dudarlo.
· Problemas que conocemos AKA codeguardfest. Escalofríos me da la gestión de memoria XDD.

Sea lo que sea será, yo prefiero un desayuno de frontend con chocos en cualquier caso, más allá del diseño de la arquitectura.

Ah, sobre bazaar vs svn (mismo argumento: svn lo hemos usado antes pese a sus penas y glorias, bazaar es la aventura) he encontrado un enlace que habla del control de versiones distribuido en inglés más-o-menos-asequible (por el contexto, como el español ;): http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

Creo que tendremos que abrir el wiki externo de todas-todas; todo este festival de correos habrá que acabar documentándoselo a gervás?.

Ah! y… felicidades anticipadas :P

RESPUESTA:

Después de haberme estudiado Python hoy debo decir que me inclino por la opinión de Adrián.

A ver, no es difícil desarrollar en Python pero tiene, desde mi punto de vista, algunos inconvenientes.

  • Debilidad de tipos: en ocasiones puede ser una ventaja pero si no se tiene mucho cuidado o experiencia en otros lenguajes de script puede ser un caos
  • No existencia de atributos privados en las clases: de hecho, no existe ningún tipo de protección. Existen mecanismos para que "medio se oculte" pero al final todo se basa en convenios de los programadores.
  • Esta es buena, multiherencia: nada de interfaces, Python posee multiherencia y eso puede dar problemas en proyectos grandes.
  • No admite polimorfismo: podéis intentarlo pero yo no lo he conseguido
  • Constructor raro y definición de métodos extraña: vease ese primer atributo pasado implicitamente llamado 'self' y el increible init(self) que constituye el contructor. Además no se puede acceder a un miembro de una clase sin utilizar la forma self.nombre-atributo

Creo que el modelado de objetos no es muy competente. Por supuesto habrá que echarle un vistazo a aquello de Python + GTK pero no me decantaría por Python como lenguaje del proyecto.

Lo hablamos en clase.

Por cierto Adri, llevas razón con que no tiene por qué todo el mundo mirarse inotify pero tranquilo. Que no llevamos ni una semana y ya hemos investigado un poco el funcionamiento básico de inotify. Ahora nos metemos a investigar el tracker y la indexación y yo estoy buscando documentos que explique cómo hacer diferencias eficientes y demás.

Sólo una pregunta, ¿en qué vamos a comprimir los backups? ¿qué librería vamos a usar?

Weno, me piro a la piltra.

Un abrazo.

RESPUESTA:

Cuestión de verlo, como decís. Comprimir dependerá de cómo guardemos las cosas, supongo que bzip será lo más eficiente. Hay que mirar xdelta para guardar diffs de binarios… Y el mismo sistema de versiones distribuido nos puede dar pistas de cómo hacer estas cosas (máxime si seguimos adelante con la idea a-medio-plazo de sincronizar dos pc's; es el mismo problema que sincronizar dos bases de código).

Una cosa importante: decidamos ya dónde alojamos y creamos, a ser posible hoy, el proyecto, wikis y demás. Así da tiempo a echar un vistazo a cómo funciona lo que quiera que usemos (a nivel documentación), y el jueves podemos usarlo en el labo de IS para escribir la papelería.

Mi voto es para bazaar + wiki externo (copón, para algo somos HDLoreal - porque lo valemos XD)… bazaar es como lo que pensaba usar (git), pero un poco más lento, escrito en python, con peor documentación… y ->multiplataforma<-, hay hasta clientes gráficos para windows (tortoisebazaar).

FIN DEL TURRON

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License