Entornos y Tecnologías de Desarrollo en el Software Libre

Agenda (1/2) Caracterización de entornos, herramientas y sistemas. Lenguajes y herramientas asociadas. Mecanismos básicos de colaboración. Gestión de fuentes. CVS. Otros sistemas de gestión de fuentes.

Agenda (2/2) Documentación. Docbook. Wikis. Gestión de errores. Sistemas de gestión de flujos de trabajo. Soporte para otras arquitecturas. Sitios de soporte al desarrollo.

Caracterización de entornos El entorno, las herramientas y VM deben ser libres. Las herramientas deben ser sencillas, conocidas y deben funcionar en arch, económicas. Modelo de desarrollo es distribuido.

Lenguajes y herramientas asociadas (1/2) La mayoría del software libre esta escrito en C. GCC es el compilador estándar en casi todas las distribuciones. Otros lenguajes que se utilizan bastante son C++, Java, Perl, Python y PHP. El idioma estándar entre desarrolladores es el ingles.

Lenguajes y herramientas asociadas (2/2) La herramienta estándar para construir programas es make. Las herramientas que ayudan a la portabilidad son autoconf, automake y libtool (C & Unix). Gettext, es la herramienta de internacionalización más utilizada.

Mecanismos básicos de colaboración En un principio solo se utilizaban cintas magnéticas. News de USENET. ej. comp.sources. Listas de correo. ej. majordomo, mailman. Foros web o weblogs. ej. Slashdot, Barrapunto. Wikis para documentos. ej. specs. IRC, interacción. ej. irc.gnome.org.

Gestión de fuentes Idea: es archivar la historia del proyecto. ¿Para que?, tener control del proyecto. Administrar versiones del proyecto. Registra la historia de los archivos, como un conjunto de diferencias sobre un patrón. Utilización de metadatos. Tipos de control: Pesimista. Optimista.

Concurrent Versions System (CVS) (1/4) Sistema de gestión de fuentes optimista. Diseñado a finales de los 80. Roles dentro del CVS: administrador, desarrollador, colaborador anónimo. El administrador del CVS, gestiona el acceso al repositorio.

Concurrent Versions System (CVS) (2/4): Colaborador anónimo Permite realizar entrega pronta y frecuente del software. Potencialmente les permite descubrir errores y reportarlos. Ejemplo de uso: #Para acceder y bajar el modulo $ cvs -d:pserver:anonymous@progs.org:/var/lib/cvs login $ cvs -d:pserver:anonymous@progs.org:/var/lib/cvs co <modulo> #Para actualizar la copia del modulo. $ cd <modulo> $ cvs update

Concurrent Versions System (CVS) (3/4): Desarrollador normal Tiene cuenta en el repositorio y acceso a escritura de los archivos. Teniendo una copia instalada del modulo, se pueden realizar las modificaciones. Primer paso antes de modificar es comprometer los cambios, de la siguiente manera: $ cvs ci parte.h parte.c Tratar de identificar mejor cada componente del proyecto.

Concurrent Versions System (CVS) (4/4): Administrador Encargado del mantenimiento del repositorio. Operaciones: dar de alta los proyectos, otorgar permisos a los desarrolladores, coordinaciones, etiquetar versiones entregadas, etc. Administración de ramas.

Otros sistemas de gestión de fuentes (1/2) CVS es el sistema de control de versiones más usado. CVS tiene varios inconvenientes: CVS esta orientado a la administración de archivos individuales. No soporta renombramientos. No soporta conjuntos de cambios. Complicado uso de ramas y mezclas. No genera Changelog.

Otros sistemas de gestión de fuentes (2/2) Algunas alternativas a CVS son: Aegis. Vesta. Subversion (sucesor de CVS). Arch. Bitkeeper. (http://linux.bkbits.net/)

Documentación (1/3) Convenientemente debe residir en el repositorio. Se prefieren formatos textuales a binarios. Compatibles GFDL. Formatos procesables aceptados; roff, texinfo.

Documentación (2/3): Docbook Antesesores linuxdoc y debiandoc. Aplicación SGML. Formato estándar de documentación libre para muchos proyectos. Su naturaleza es compleja y llena de etiquetas. Importante disponer de herramientas de ayuda a la edición.

Documentación (3/3): Wikis Alternativa a la complejidad de escribir Docbook y manejar CVS. Elaboración de documentos en linea. Lenguaje de marcas simple y conciso. Propio control de versiones de los documentos.

Gestión de errores Idea: Contribuir con informes de error, y aportar en la solución. Existen sistemas de gestiones de errores, que trabajan; vía web, vía email o vía un programa intermedio. Todos tiene interfaz web para consultas. Unos permiten informes anónimos, otros requieren autenticación(email). Ejemplo reportbug de Debian GNU/Linux.

Sistemas de gestión de flujos de trabajos En el software libre no hay mecanismos tan sofisticados de gestión de los trabajos. Sirven para definir tareas. Se espera que alguien se dé de alta en el sistema, asuma una tarea y declare un plazo. Ejemplos Bugzilla. Issuezilla.

Soporte para otras arquitecturas Probar la portabilidad del proyecto. Acceso a granjas de compilación. Esta infraestructura se denomina Tinderbox. Algunos proyectos que utilizan Tinderbox; Mozilla, Openoffice, FreeBSD.

Sitios de soporte al desarrollo (1/4) Proporcionan todo los servicios nombrados anteriormente. Servicios se entregan de forma integrada. Adicionalmente permiten busquedas y clasifican los proyectos. Libera al desarrollador de montar toda la infraestructura. Ejemplos: SourceForge.

Sitios de soporte al desarrollo (2/4): SourceForge Sistema de colaboración, administrado por OSDN. Alberga más de 100.000 proyectos. Subsidiaria de VA Software. Ofrece un portal global de entrada y un subportal por proyecto. Dentro de cada proyecto se puede ver su descripción, estado, descriptores. Software libre hasta su versión 2.

Sitios de soporte al desarrollo (3/4): Herederos SourceForge Crisis de las puntocom. VA Software anuncio cambio de licencia. Se eliminaron los mecanismos para llegar los proyectos a otro sitio. Herederos. Savannah. BerliOS.

Sitios de soporte al desarrollo (4/4): Otros sitios y programas Tigris: Proyectos de ingeniería de software libre. Gforce: Utilizado en el proyecto Debian GNU/Linux.

Preguntas y Respuestas