principal nivel superior enviar artículo buscar administrar acerca de ... rdf rss main |
from the dept. Birdcage ya esta listo para el empaquetado, sin embargo quedan algunas cosas operativas por resolver, primero lo de las versiones, después de una revisión de la Wikipedia y los sitios relacionados sobre como llevar la numeración de versiones [1],[2], es mas o menos consistente con la que usa Panx en el roadmap, sin embargo yo encuentro que es la 0.5.5 la que está actualmente puesto que es la entrada marcada en el 28 de mayo de 2008, ya que la siguiente es de febrero de 2009 donde cambia a ouroborus 0.2.0, antes de esto más o menos había seguido la regla de cambiar de versión cada vez que se añade una nueva funcionalidad, se avanza en grande o se hace un gran cambio es decir 0.1 a 0.2, añadir un numeral cada vez que se cambia algo, se hacen pruebas o se arreglan cosas es decir 0.2 a 0.2.1 (de hecho recomiendo no usar mas de tres, para evitar lo que tuvo el kernel de linux en su momento y ser mas claros en la numeración) [3], el problema real que veo con la numeración es que de esa entrada en febrero de 2009 existen muchas modificaciones a birdcage que podrían ser cambios en la numeración, de hecho me preocupa que en el roadmap se salta de la versión 0.6 (working) a la 0.9 y de ahí a la 1.0 en la propuesta con deadlines y en el extendido tan solo esta hasta la 0.5.5. Ahora todo lo demás que esta en el svn de sourceforge y que se ha modificado en birdcage no se refleja en la numeración de versiones, ¿vale la pena recuperar eso para ver en que versión estamos o juntamos todos esos cambios y decimos que es la versión 0.6 – ya que ahora funciona con cython –? o de plano brincamos a la 1.0 para decir que es ya no es beta, es decir el primero de producción El otro gran detalle es la elección de la licencia, entiendo que el código esta basado en trabajo previo, ¿conocemos la licencia de este trabajo previo? O se re implemento desde cero y entonces podemos elegir la licencia nosotros o en su caso Panx, sobre lo que se comentaba el otro día, a mi me gusta mucho la GPL2 por que es una licencia que conozco hace mucho tiempo y me parece buena, especialmente la V3 no la he leído en su totalidad y entiendo que existe algún descontento entre los desarrolladores, pero esa es una tarea que tendré que hacer por lo pronto. El sábado 20 de noviembre tuvo a bien quemarse una hilera de capacitares en la motherboard de Sagan así como la fuente de poder [4], el lunes 22 se hablo con redes y reportaron que el botón de encendido que normalmente es un led con color verde estaba en amarillo, buscando en la red, en el diagnostico del modelo, eso significa falla en la alimentación o en el motherboard, el martes 23 se llevo a reparación y se lleno la hoja de servicio, el 24 se puso en línea de nuevo y fallo por la tarde de ese mismo día, el 25 se reinicio la maquina y se le hizo varias pruebas de estrés utilizando siege para probar la carga de la maquina y cpuburn. Resultado de eso se modifico la configuración del Zope, para limitar la cantidad de memoria que esta utilizando, mejorar el como se están llevando los logs, en especial no llevarlos semanales sino mensuales y rotarlos cada 6 meses, en cuanto a los hilos que requiere también se limitaron ya que no somos un sitio tan visitado y los buscadores justo son los que hacen mayor cantidad de trafico en el sitio. Se pidió mas RAM para la maquina, actualmente tiene instalado 1GB de máximo 4 esto se espera pronto se resuelva. Finalmente trate de hacer un empaquetado para probar aprovechar para releer el new mantainer’s guide [5] y me tope con que ahora el documento añade herramientas que se encuentran en squeeze por lo que en mi instalación normal no lo pude terminar, uno de mis espacios de desarrollo que esta en un chroot fue acondicionado para intentarlo de nuevo, pero aún tengo que familiarizarme con varias herramientas que no se usaban antes Tareas continuas Mantenimiento de las maquinas en Ajusco [0] y el sitio del ICME (se espera la fecha para convertirlo en contenido estático). Pendientes Escribir un roadmap del empaquetado (más o menos delineado en este post) Leer los siguientes documentos http://www.debian.org/doc/debian-policy/ http://www.pathname.com/fhs/ http://www.debian.org/doc/packaging-manuals/debconf_specification.html http://www.debian.org/doc/developers-reference/ http://bugs.debian.org/debian-policy Empaquetar Birdcage Leer y comprender la GPL version 3. http://www.gnu.org/licenses/gpl.html http://www.gnu.org/licenses/quick-guide-gplv3.html http://www.gnu.org/licenses/agpl.html http://www.gnu.org/licenses/why-affero-gpl.html [0] http://linux.ajusco.upn.mx/wiki/index.php?title=Uroborus#Servers_and_services_available [1] http://en.wikipedia.org/wiki/Software_versioning [2] http://tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html [3] http://en.wikipedia.org/wiki/Software_versioning#Modifications_to_the_numeric_system [4] http://www.badcaps.net/forum/showthread.php?t=2607 [5] http://www.debian.org/doc/maint-guide/ < Reporte de actividades | Lagartijas Amazonas Vietnamitas >
|
|
|||||||||||
|
"Any system that depends on reliability is unreliable." -- Nogg's Postulate | ||
All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest ©1999 Butch Landingin. |