Índice
|
Table of Contents
|
Introducción
Aquí centralizamos todo aquello que trate sobre procedimientos y estándares que vamos a seguir en el proceso de desarrollo del software. Se utiliza también como método de comunicación en el grupo.
A fin de poder subdividir el trabajo lo más posible y especializarnos, dividimos lo que, a grosso modo, hay que hacer para cada entrega.
Procesos, procedimientos y estándares
- El modelo de desarrollo a seguir para el código queda establecido como propuesta-modelo-desarrollo, a falta de probar en condiciones reales su viabilidad.
- De la formación del personal se encargan los tutoriales, que no solo tratan de tecnologías específicas de cada grupo de trabajo sino también de todo lo necesario como el control de versiones. Que todo el mundo documente sus tecnologías, así minimizamos el riesgo de que se nos caiga alguien y nadie sepa cómo seguir su trabajo.
- La evaluación de la calidad queda asignada a Mario (rastas ;), que se encargará de seguir si funcionan los procesos y modificarlos según sea necesario. También, y prácticamente por último, deberá comprobar inconsistencias internas en la documentación a fin de clarificarlas y solventarlas, así como la calidad final de la misma (legibilidad, etc).
- El estándar de documentación en wiki es sencillo: Todo aquello que vaya a ser incluido a posteriori debe empezar con el header de tamaño 2: ++, para que con el de tamaño 1 se pueda categorizar al incluirlo. A partir de ahí, se ruega la máxima legibilidad y corrección, así como la estructura que se considere adecuada mediante headers. Se ruega a cada equipo que documente en el wiki todo lo posible (si hay nuevos casos, si se modifican o amplían los existentes, etc).
- Todo fragmento de documentación exigido por Gervás debe tener como padre (o abuelo, vaya) doc, como categoría doc: y *debe comprobarse* que queda incluido correctamente en printable
- Para poner fragmentos de código se *debe* usar la etiqueta [code].
- Respecto a los comentarios, ya lo he mencionado en lista de correo: No dejéis comentarios entre la documentación, usad las páginas de comentarios de cada página y así los podemos ver juntos… Si echáis en falta la sección comentarios, añadidla con :
[[div class="comentarios" ]]
+++ Comentarios: [!--anidamiento según la página--]
[[module Comments title="" hide="true"]]
[[/div]]
Con esto solucionaremos el tema de flujo de información interna en el proyecto sin riesgos a la calidad de la documentación final.
- El estándar de código seguirá estandar-codigo. Se escribirá lo más posible en inglés, para facilitar salidas posteriores a nuestro proyecto.
- El estándar de documentación de código (implicado en el anterior) seguirá doxygen.
* Mientras se encuentre un modelo mejor de comunicación, se ruega no dejar comentarios en las páginas de documentación. Intentaré explorar la posibilidad de las "talk pages" al estilo de la discusión sobre un tema de wikipedia.
- Falta establecer calendarios internos de entregas…
Entrega 1
Included page "entregas:noviembre" does not exist (create it now)
Grupos de trabajo:
Aquí subdividimos los áreas de trabajo que hemos identificado en el proyecto, y cada equipo de trabajo lista sus miembros y tareas pendientes por prioridad.
Aquí es donde ponéis qué vais a hacer, y en qué orden
Documentación (wiki)
Entre Mario y Ezequiel nos encargaremos de intentar mantener esto al día y correcto; toda ayuda es bienvenida, nos ahorraréis muchas horas de lectura.
Ruego a todo el mundo que empiece a volcar "esto" a casos de uso, para intentar implementarlos directamente. Si detectáis inconsistencias que no sepáis resolver a priori avisad y se decide sobre las mismas entre quien corresponda (las que sepáis resolver, ya sabéis ;).
Además es necesario crear un glosario "serio" ;), y juntar las tablas de riesgos en una sola según su indicación.
Control de calidad
Como está registrado, se encarga Mario y se le echa una mano entre todo aquel que detecte problemas. Consistencia interna, "hortograflíha", legibilidad, código comentado, etc. Más adelante tendrá mucho que decir en la integración del código; posiblemente reorganizaremos para tener más gente aquí.
- Seguir las indicaciones de calidad de Gervás sobre consistencia (Creo que ya está arreglado?).
- Establecer estándar de código, al menos para el backend. Más allá de Camelcase para funciones y documentar con doxygen, hay que pensar cosas como cómo imprimir a consola, y cuánto (—debug, para entendernos).
Procesos de desarrollo
Ezequiel (yo :P) se encarga en la medida de lo posible de documentar procesos y decisiones que se tomen al respecto en esta página. El wiki es colaborativo; invito a todo el mundo a usarlo :).
Importante Tenemos a un chico nuevo en el messenger pero no sabemos nada más de él… Hay que hablar con él ya.
update 7-11-2007 A fecha de hoy, nadie ha subido código del gui a launchpad. Ruego probéis
Arquitectura del sistema
Hemos definido ya una arquitectura básica, separando responsabilidades en componentes. Se ruegan opiniones.
el documento original está en ~hdlorean/testing bajo la carpeta doc, es un archivo de Kivio
GUI (pygtk + glade)
El grupo de trabajo lo forman Fede, Tabas, Rober y Carlos. La prioridad es conseguir un prototipo (no necesariamente funcional) lo antes posible para poder entregar en noviembre; sugiero inspirarse en proyectos "parecidos". El caso de uso es la interfaz con usuario y la configuración del programa. De ahí que tenga tanto personal.
Recomiendo (eze) un configurador independiente separado en tabs según el área de la configuración, evocable tanto desde el gui independiente, como desde la integración con nautilus, como desde las preferencias de gnome, que a su vez pueda invocar diálogos de opciones avanzadas y un asistente que sería el inicial del programa. El configurador escribe en un archivo .config/hdlorean/prefs.cfg (estándar freedesktop es algo así), y notifica al programa de cambios por una señal dbus (por ejemplo, o el backend se está atento al prefs por si se edita a mano, o se le obliga a recargarlos por si se edita a mano). El archivo de configuración puede ser más extensivo que el configurador (para eso está!), aunque recomiendo que no haya opciones que no sean configurables por gui (aunque sea mediante "avanzado…").
Comunicación GUI / Backend (dbus, archivo de configuración)
Por ser parte fundamental del código del gui y estar más definido por las necesidades del usuario que las del backend, también se asigna al grupo de Fede, Rober, Tabas y Carlos. Su prioridad es secundaria (primer prototipo no es funcional aún, pero hay que definir interfaces lo antes posible).
Lógica de programa (módulo Jijona)
En la lógica de programa gestionamos qué hay que hacer y a quién se le pide, bajo órdenes del usuario. Pediría que todos arrimásemos el hombro con esto (va relacionado con la arquitectura), pero a nivel de código intentaremos juntarnos el grupo de gestión de cambios y el de bases de datos para escribir un API adecuado. El sql y demás debería deducirse más-o-menos de ello.
Base de datos (interna al programa)
Ezequiel, David, Mario. La sección de la base de datos se encarga de gestionar la información interna del programa que vayamos a necesitar. Sugiero dos áreas: uno el "journal", que escribe lo más rápidamente posible los cambios que vamos encontrando, y otra que gestiona dónde-está-cada-cosa, y cómo. Además hay que encargarse de los cambios al almacenamiento (externalizar, borrar snapshots, recuperar, etc).
Es el core de la aplicación y falta gente; entre Mario y yo no podemos ocuparnos de esto y del wiki.
(eze) Recalco que mi sql-fu es débil; para diseñar la base de datos sí puedo estar, pero escribiendo querys soy un inútil. Habrá que echarnos una mano desde lógica de programa.
Gestión de cambios en archivos (detección / procesado)
Adrián, Diana y me falta gente. Encargados de detectar los cambios en archivos.
La prioridad es explorar métodos para ello y conseguir implementaciones lo más pronto posible (inotify, rsync, diff, etc), para avisar al centro de la aplicación. Además hay que repsonder a señales del usuario (snapshots voluntarios -> volcar a casos de uso!) y, en un futuro, planificar escrituras para evitar escribir de más (p.e. si un cambio lo capturan a la vez un snapshot completo
En principio lo lógico sería que corriese en un thread independiente del resto del sistema (nunca se dejan de generar eventos de inotify!).
Almacenamiento a disco (snapshots)
Salva se encarga de explorar esto. Se trata de ver cómo se guarda a disco, modularizarlo lo más posible, y definir los formatos de compresión. Posiblemente usará enlaces duros y xdelta para incrementales. También se ocupa de externalizar a CD / disco duro externo / etc y coordinarlo con la base de datos.
Integración GUI (nautilus)
La integración con nautilus es importante para conseguir transparencia real de cara al usuario, pero vista la poca documentación para realizar extensiones queda pendiente de una futura iteración de proyecto.
Empaquetado
Aquí queda englobado el tema de instalación del software, requisitos, etc. Queda pendiente de avanzar un poco el desarrollo, para ulteriores iteraciones más completas.
Integración metadatos (beagle)
La integración con beagle, si bien interesante y necesaria para duplicar funcionalidad de time machine, queda pospuesta ante la necesidad de investigar el api, su bajo riesgo en caso de carencia y la falta de personal.
Personal
no se me enfaden si se me pira o me dejo a alguien, después de escribir todo esto se me va un tanto el panchito.
Ezequiel: Wiki / procesos / bases de datos - core del app. lo siento sres pero no doy abasto.
Mario: Control de calidad / wiki / bbdd - core.
Adrián: Gestión de cambios / lógica de programa (lógica de Jijona)
Jorge: Gestión de cambios. lógica de programa (lógica de Jijona))
Diana: Gestión de cambios. lógica de programa (lógica de Jijona))
Salvador: Escritura a disco. lógica de programa (lógica de Jijona) (sé que echarás una mano con eso, no nos queda otra…)
Fede: GUI - dbus
Rober: GUI - dbus
Tabas: GUI - dbus
Carlos: GUI - dbus
David: bbdd
Daniel(el chico-nuevo) -> ? Echar una mano a salva.
