Ideas

Podemos utilizar esta página como sustituto de la lista de correos. Que cada uno vaya añadiendo en la primera línea lo que tenga que decir. Si son respuestas, lo podéis poner en cursiva después de cada línea. Si ponéis vuestro nombre delante, mejor que mejor para saber quién dice qué.

• [Eze] aunque esté deprecadísimo esto… Mark shuttleworth en su propuesta de releases sincronizadas en todo el mundo gnu/linux:

A comprehensive test suite, on the other hand, lets you be more open to big landings on trunk, because you know that the tests protect the functionality that people had *before* the landing. A test suite is like a force-field, protecting the integrity of code that was known to behave in a particular way yesterday, in the face of constant change. Most of the projects I’m funding now have adopted a tests-before-landings approach, where landings are trunk are handled by a robot who refuses to commit the landing unless all tests passed. You can’t argue with the robot! The beauty of this is that your trunk is “always releasable”. That’s not *entirely* true, you always want to do a little more QA before you push bits out the door, but you have the wonderful assurance that the test suite is always passing. Always.

So, branch-friendly VCS’s and test-driven development make all the difference. Work on your feature till it’s done, then land it on the trunk during the open window. For folks who care about the release, the freeze window can be much narrower if you have great tests.

• [Eze] ¿Je, hace cuánto que no miráis esto? XD aunque ya lo colgué en una planificación… http://www.useit.com/alertbox/application-mistakes.html

En concreto:

* If a command takes more than 1 second, show the "busy" cursor. This tells users to hold their horses and not click on anything else until the normal cursor returns.
* If a command takes more than 10 seconds, put up an explicit progress bar, preferably as a percent-done indicator (unless you truly can't predict how much work is left until the operation is done).

…
People don't know the workflow or the steps, they don't know the expected outcome, and they don't know the basic concepts that they'll be manipulating.

• [Salva] Deberíais actualizar vuestros módulos porque es una forma bastante rápida de estar al tanto de los cambios.
• [Eze] aunque ignoro si seguís leyendo el front de vez en cuando… He aquí un link para la gente del ui que os puede interesar si tenéis un ratito para leer: http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
• [Eze] Reunión cuanto antes (martes? como máximo!) para poner en condiciones la entrega de noviembre, que se entrega el jueves => se le envía a Gervás el miércoles como tarde. Mientras tanto, no dejéis de ver este vídeo http://youtube.com/watch?v=o3TGM0T1CvE … entenderéis por qué mola ZFS, por qué *también* resolverá nuestro proyecto cuando tire en linux, y por qué uso bsd (joder, hay que ser notas para hacer ese video! XDD).
• [Salva] A mi me parece la opción más correcta. Entonces el nombre del proyecto queda en HD Lorean y para código, carpetas de instalación y demás usos: hdlorean ¿no?
• [eze] nombre del proyecto. Como veo que cada uno lo escribe como le da la gana, propongo ser consistentes. Mi voto es para HD Lorean en todo lo que sea documentación, y hdlorean en todo lo que sea código (de hecho ya está así en launchpad). Ni HDLorean, ni HD-Lorean, ni HDlorean, ni HdLorean…
• [Fede] Poll: El código, y casi que la documentación y el interfaz gráfico no deberíamos tirarlo en inglés? Fede vota sí. (Adri) yo tira código en inglés. Aunque los comentarios no los he tirado en inglés, sí los doxygen. Adri vota sí (Salva) Por mi, también lo tiraría todo en inglés. Salva vota sí [Eze] Yo voto yes y os jorobo el parser XD. //
• [Eze] Otro Proyecto hermano que me he encontrado. En los comments les ponen que por qué no usan rdiff-backup… Habría que explorar qué es, pero *creo* que soluciona lo de xdelta de almacenar cambios… En slashdot hablan del tema (pero no salimos :P)
• [salva] Ahora que he visto que se pueden hacer includes dentro de includes porqué no volvemos al modelo original con todo bien ordenadito por listas. Ahora tan solo habría que hacer un sólo include por cada item nuevo. Lo digo porque, aunque se que es un coñazo reformatear para dárselo a Gervás, no podemos olvidar que la wiki tiene que servir nuestra comunicación. //(eze) Ya, pero con casos de uso e historias es un coñazo y seguro que se olvida meterlo a doc:printable, con lo que nos toca ir detrás de la gente a añadirlo; con la edición por secciones funciona también, y además ahora empezaremos a darle bastante tute a los casos de uso porque toda funcionalidad de código hay que documentarla en caso de uso … Así en realidad es más cómodo trabajar.
• [salva] Para los deprecated, por qué no los borrais pero diciendo que sólo los renombre a deleted:blablabla o por qué no hacemos una categoría deprecated y así mucho mejor? Así nos ahorramos nombres como casos de uso merged que no son demasiado humanos, os parece? (eze) Arreglados los casos de uso y las historias; me parece bien lo de deleted: (de hecho es el borrar por defecto, solo que default no todos podemos borrar páginas)
• (eze) Os ruego que cuando hagáis una página que cuelga de documentación no uséis un único "+" para encabezados; empezad siempre por "++". Así reservamos el nivel 1 para donde se incluya esa página (por ejemplo printable y todo queda colocadito y precioso en la tabla de contenidos. Gracias…
• (eze) He estado recolocando un poco todo, metiendo anchors donde faltaban, etc. He vuelto a romper la tabla de riesgos en tres separadas; si no es un sacrosanto *cognazo* editar un riesgo en las tres partes en las que se compone. Alternativamente: componer las tres tablas en una… Pero yo no me presento voluntario para *eso*, así que he seguido editando en las tres separadas. Para ahorrar follones de inclusión están incluidas tanto en riesgos como en el printable (todo sigue funcionando, en resumen). Os agradeceré que me deis el visto bueno con esto y los riesgos curremos en tablas separadas (total, son tres solamente y nunca cambian).
• [Adri] http://hdlorean.wikidot.com/estandar-casos-de-uso <~~ ¡Leedlo!
• [Fede] Estoy haciendo la documentacion "printable" pero es lo puto peor, hay que andar incluyendo cada página hija si quieres que salga en el sitio printable, y esto nos crea problemas. Creo que si vamos a migrar, pues migramos a algo en lo que se pueda decir [[include fulanito:ChildPages]], y si no, se acabó el crear nuevas páginas por cada caso de uso, y lo que editamos son las secciones de la misma página: casos de uso.
• [Salva] He dedicado esta mañana a organizar cosillas y lo que me dijiste, Eze, sobre la navegación, ya está hecho. Además, he cambiado algunas listas por mapas autogenerados y creo que todo queda bastante mejor. He sacado de documentación todos los includes (pero siempre se puede volver atrás) porque me parece una redundancia. Para eso no listamos las partes. Weno, espero que os gusten los cambios. Esta es mi última contribución esta semana. Pasad una buena semanita y, por favor, avisadme de cualquier cosa importante. Un abrazo.
• [Salva] Una cosa referente a tutos, si vais a poner codigo utilizad la forma [[code style type="lenguaje-programacion"]] porque colorea la sintaxis.
• [Salva] Avisadme de lo comentado en la reunión por favor. Ando hasta arriba de lios pero solo por esta semana.
• (Carlos) Ayer en clase vimos los riesgos, y Gervás nos dijo que deberíamos ir empezando a pensar en ellos. Esta tarde en la reunión habrá que dividirse para casos de uso y riesgos, no os parece?
• (eze) Un tutorial de cómo usar rsync para snapshots.
• (eze) Una review decente de Leopard entero, y Time Machine en particular. (Fede) Imperdible también la parte de FSEvents, que vendría a ser el inotify+beagle que hay en Leopard.
• (eze) Empezados los tutoriales
• [Jorge] Se había comentado la posibilidad de ofrecer un API para thirds…pero no aparece nada en las historias(y por supuesto tampoco en los casos de uso). Dejo el comentario aquí… y en la próxima docutón lo hablamos. (eze) lo que más se parece es lo del juego, convendría ampliarlo con otra nueva para buscar un correo o un log de mess. También falta el de "busco por contenido en trac^Wbeagle y me busca en la historia". //
• [Salva] Para las listas y demás, yo no pondría toda la lista sino sólo el enlace a la misma porque si no, hay que estar actualizando en todas partes. Si os parece bien, las borro en algunos sitios.
• (eze) Tengo una propuesta de modelo de desarrollo. Es un poco tochazo, pero os pediría que la miraseis con un poco de atención y me dijeseis si os parece razonable. He intentado ser lo más claro posible, palabrita.
• (adri) He estado mirando y junto con Eze, creemos que es mucho mejor usar Beagle que Tracker. Tracker no dispone de un API de alto nivel para desarrollo de aplicaciones externas y Beagle sí. La pega es que Beagle está en C#, pero no os creáis que el C de Tracker es una maravilla, he ojeado el código y los ficheros de 1500 lineas tienen una media de 15 comentarios, así que… Además Beagle es más maduro y tiene más documentación. Además, mirando el código de Beagle, tiene muchos más comentarios y está orientado a objetos como dios manda. http://beagle-project.org/Development y http://beagle-project.org/Architecture_Overview
• No podriamos usar el wiki como forma de entregarle a Gervas las cosas?Se le podría invitar y asi podría ver cuando quisiera las cosas que vamos haciendo, incluso podría poner comentarios de esto me gusta esto o esto no (si el lo cree oportuno claro)Que os parece si se lo comentamos?nos va a decir que tararí EMHO
• Y cito de una review de nuestra "inspiración": //[…] leads to a remarkable change in mindset: I just installed a new version of a program I’m beta testing, and realized that if it didn’t work, I could quickly roll back to the previous version via Time Machine. Claro, eso rula solo en ese-OS porque allí los programas instalados son carpetas sin +… Pero vaya canteo más chulo.
• Hector me ha facilitado un página que seguro que nos viene muy bien para facilitarnos el trabajo. Me ha dicho que entregaron 40 casos de uso.
• He cambiado los casos de uso y se han reordenado. Ver nota en el cuerpo del wiki o comentarios del fuente de casos de uso… así no hay que actualizar las listas a mano, pero se ordenan solos por orden alfabético. qué-era-cada-uno sigue estando en la historia (lo bueno de la wiki es que *no* se pierden datos al editar).
• He abierto página en launchpad, pero como no sabía la licencia la he dejado pendiente, y ello ha bloqueado la creación a falta de que canonical apruebe una licencia de "aún no está decidido, pero como mínimo GPL". Veremos si logro recuperarlo. Convendría decidir la licencia (aunque si vamos a usar código GPL está decidida de antemano: GPLv2).
• Por si nos sirve: HOWTO_Backup de gentoo
• Idea de uso: según me comentaban hoy sobre TimeMachine, una feature gorda y no-fea es que tú haces una búsqueda con spotlight, y si no te aparece ningún archivo tienes un botón para buscar en la historia del finder. Le das, y van pasando las vistas de las carpetas hacia atrás hasta que aparece la que tiene el ->contenido<- que has buscado (puede ser una frase dentro de un archivo, vaya). Para ESO queremos tocar en Tracker. Sin meternos en metáforas visuales tan tensas, podemos hacer lo de ir pasando hacia atrás la barra de tiempo, y quizá un osd tipo amarok (ventana o mensaje sobre todas las demás) con un reloj y las agujas moviéndose cuando toques la barra del tiempo (con el reloj de Cairo p.e.?). Usabilidad!!!
• ¿Escribimos tutoriales para nosotros mismos en el wiki?
• Voluntarios para volcar los correos que han circulado ya? gracias robs

*[Ender] Se podría hacer que se instalara directamente al conectar un disco duro con el paquete incluido? Sería genial llevar el disco externo al labo y que se instalase ahí de pro