comienzo con la interpretacion de "Introduccion al desarrollo de Ubuntu", por Daniel Holbach antes de comenzar me gustaria dar algunos tips, que les ayudaran a disfrutar del evento primero, asegurense de entrar a #ubuntu-classroom-chat #ubuntu-classroom es solo para la clase, la platica y preguntas se hacen en #ubuntu-classroom-chat si tienen alguna de ellas, haganla usando el prefijo QUESTION: ejemplo, QUESTION: Can you recommend any good music for a late-night hacking session? si tienen problemas para hacer su pregunta en ingles, haganla en este canal, y con gusto les ayudaremos a hacerla en la sesion original tambien, es buena idea que revisen https://wiki.ubuntu.com/UbuntuDeveloperWeek si desean conocer el calendario de las charlas que se estaran haciendo dos de las preguntas mas frecuentes que se hacen son: 1.- abran logs de las charlas disponibles? para esa pregunta, la respuesta es si, se pondran en https://wiki.ubuntu.com/UbuntuDeveloperWeek/ para la interpretacion, los logs estaran disponibles en https://wiki.ubuntu.com/SemanaDesarrollador la segunda pregunta es: 'como puedo ignorar todo el ruido que se genera, cuando las personas entran y salen de la sala?' para esa pregunta, la solucion es escribir "/ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS" en la ventana de este canal sin el " obviamente en fin, eso es todo lo que dire sobre los aspectos organizacionales, que comiencen las sesiones! =) mi nombre es Daniel Holbach, he estado trabajando en Ubuntu por casi todo el tiempo que lleva existiendo y siempre me ha gustado nuestra comunidad he trabajado durante años para canonical, comence en el equipo Desktop, y despues como parte de nuestra comunidad de desarrolladores durante esta sesion, les mostrare como funciona en general el desarrollo de Ubuntu al principio parecera un caos, debido a que siempre hay personas modificando cosas por todos lados, sin embargo, pronto se daran cuenta de lo facil que es :) tambien me gustaria responde la mayor cantidad de preguntas posibles si voy demasiado rapido, o lo que digo no les hace sentido, comentenlo =) Ubuntu esta hecho de miles de diferentes programas, todas ellos escritos en diferentes lenguajes, cada componente - ya sea una libreria de software, una herramienta del sistema, o una aplicacion grafica, esta disponible como un paquete, y el codigo fuente de dicha aplicacion integrado en el los paquetes consisten en la mayoria de los casos, de 2 partes, el codigo fuente en si, y metadatos que describen el paquete, esto incluye las dependencias, el copyrigh y las instrucciones sobre como compilar el programa una vez que se compila, el proceso de construccion crea un paquete binario, estos paquetes binarios son los archivos .deb que los usuarios instalan cada vez que se libera una nueva version del programa, o que alguien hace una modificacion, el paquete debe subirse a Launchpad, ahi, sera recompilado los paquetes .deb que resulten, seran distribuidos a traves del archivo y los diferentes mirros de ubuntu alrededor del mundo. Las urls que se encuentran en /etc/apt/sources.list apuntan a esos repositorios todos los dias, diferentes imagenes de Ubuntu se crean, por ejemplo, ubuntu desktop, ubuntu server, kubuntu, etc. Estas imagenes para CD se utilizan para hacer pruebas y hacer comentarios sobre los planes de lanzamiento como nota al margen, debo mencionar que durantes los ultimos 2-3 ciclos, hemos comenzado a crear un enorme laboratorio de QA, en el se varias pruebas en toda clase de programas, esto obviamente tambien es tomado en cuenta para modificar los planes de lanzamiento el desarrollo en Ubuntu, depende de alguna forma, del estado del ciclo en el que se este liberamos una nueva version de Ubuntu cada 6 meses, esto solo es posible debido a que establecemos fechas estrictas donde prohibimos hacer mas cambios (freeze dates) con cada nueva de estas fechas, se va sugiriendo a los desarrolladores introducir menos modificaciones si hechan un vistazo a https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule veran las fechas importantes para la version actual de Ubuntu, la 12.10 como podran ver, acabamos de pasar la fecha de congelamiento (feature freeze) esta fecha, es la primera de las que se daran para detener el desarrollo, y se da despues de haber avanzado la mitad del ciclo. Despues de esta fecha, la mayoria de las caracteristicas que contendra la proxima version de Ubuntu deberan estar hechas, el resto del ciclo se utiliza para pulir la distribucion, y para corregir los bugs que se encuentren despues de esta fecha, se empiezan a prohibir cambios en la interfaz grafica, en la documentacion, en el kernel, etc.., una vez hecho esto, se liberan las versiones beta, las cuales se prueban en gran cantidad de usuarios y son consideras muy estables se solucionan unicamente los errores criticos, hasta que se eliminen todos, cuando esto pasa, la version beta se convierte en final, y esa es la que se pone a disposicion del publico en general alguna pregunta hasta el momento? marcos pregunta si QA significa 'Question and Answer'/'Pregunta y respuesta'? dholbach responde que de hecho significa 'Quality Assurance' o 'Aseguramiento de la calidad' lo que a su vez significa que es donde se hacen toda clase de pruebas, tanto automaticas como manuales, tambien es donde se hacen pruebas de la integridad de los CD, y donde se verifica que los sistemas son instalables, entre otras cosas QA es lo que hace que Ubuntu en lugar de ser bueno, sea excelente conner_bw pregunta sobre el criterio para definir que 'ya no hay ningun problema critico' dholbach responde que aunque no hay un criterio extremadamente formal, el que se pierdan datos, o que existan aplicaciones cruciales que no funcionen (y con aplicaciones cruciales se definen las que vienen en un sistema Ubuntu por defecto) es sin duda un critero que se toma en cuenta para decidir si esta o lista la distribucion agmenor_ pregunta sobre la version de Ubuntu que tienen que correr los que son desarrolladores de aplicaciones dholbach responde que en ese caso, seria suficiente con usar la ultima version estable, es decir, la version 12.04 aunque si desea modificar a Ubuntu directamente, necesita correr la ultima version en desarrollo, es decir Ubuntu 12.10 esto es asi porque los cambios deben probarse antes de su inclusion paulo_gomes pregunta que es lo que pasa, cuando una nueva aplicacion es liberada pasada la fecha de congelamiento de ubuntu, se tiene que esperar hasta la proxima version de Ubuntu? dholbach responde que depende, si el software es liberado antes de la fecha de congelamiento, puede incluirse sin problemas, si es una actualizacion que arregla problemas importantes, puede que pase incluso despues de la fecha de congelamiento, sin embargo, conforme vayan pasando los dias, cada vez sera mas dificil convencer al equipo que se encarga de la liberacion de Ubuntu (el release team) esto es por una buena razon: se necesita tiempo para probar las cosas hablare sobre eso un poco mas adelante conner_bw vuelve a preguntar sobre el criterio para definir los errores criticos que impiden el lanzamiento de Ubuntu, esto lo hace, porque usando 12.04 esta inscrito a algunos bugs que a su consideracion son muy importantes, y que no detuvieron que Ubuntu 12.04 se liberara, por ejemplo la integracion del launcher de LibreOffice dholbach responde que algunas veces se tienen que tomar decisiones que permitan liberar Ubuntu el dia en el que esta marcado, este proceso no es facil, pero tiene que hacerse Liverpudlian pregunta si las aplicaciones se desarrollan de diferente manera cuando se crean para versiones LTS obounaim pregunta sobre la url del equipo QA dholbach da la liga https://wiki.ubuntu.com/QATeam/ y sugiere que se lea como introduccion a las actividades que realiza el equipo dholbach responde a Liverpudlian que definitivamente, y agrega que muchas personas deciden utilizar esas versiones por mucho tiempo, asi que los autores se esfuerzan por hacer que sus aplicaciones sean incluidas C1sM0 pregunta si los archivos .deb se crean automaticamente una vez que el codigo fuente se sube a launchpad dholbach responde que si, aunque eso puede tardar un poco, porque se organizan en filas, debido a la falta de maquinas asignadas para compilar que se tienen en launchpad sin embargo, la espera comunmente es de menos de 1 hr nja pregunta porque la seccion de trabajo en el calendario de lanzamiento de quantal dice A-2 en lugar de A-1 dholbach responde que realmente no esta seguro, y pregunta si se refiere a lo que aparece en http://status.ubuntu.com/ubuntu-quantal/ agreta que tal vez se deba a que la ultima version intermedia fue la Alpha 2, aunque confirma que no tiene idea marcos pregunta si el concurso App Showdown acepta aplicaciones privativas / comerciales dholbach responde que hasta donde sabe, no dholbach pide que por el momento, las preguntas y la charla se centre en el desarrollo de Ubuntu por si mismo, y se deje el tema de las aplicaciones para las siguientes sesiones, agrega que parte de lo que ahora mismo se discute (como las fechas de congelamiento) aplican para ambos temas _et pregunta si usan C-I para compilar los paquetes dholbach responde que no conoce de C-I, pero que todos los programas, se compilan en launchpad, que es un plataforma de software libre hecha a partir de Zope/Python, y que el sistema de compilacion por si mismo se hace con la ayuda de 'sbuild' ziviani pregunta sobre la personas que definen las caracteristicas que se implementan en un ciclo, y tambien sobre que pasa, con aquellas que no pudieron implementarse antes de la fecha de congelamiento (freeze date) dholbach responde que aquellas caracteristicas que no pueden completarse, se dejan para el siguiente ciclo, y que las decisiones sobre lo que se hace las toma el equipo de lanzmiento (el release team), y los respectivos lideres de los sub equipos de ubuntu nja pregunta porque la aplicacion Lernid tiene una terminal dholbach responde que es porque cuando los ponentes deciden hacer algun ejercicio, los asistentes pueden correrlo en su sistema marcos pregunta si las versiones estables, como Ubuntu 12.04.1 aceptan nuevas caracteristicas dholbach responde que no, que lo "unico" que se acepte son actualizaciones de seguridad, correccion de errores pequeños, nuevas traducciones y cuestiones por el estilo, que sean seguras de implementar y agrega que con los recursos actuales es muy dificil concentrarte en ambas versiones (la 12.04 y la 12.10 por poner un ejemplo) Henrich pregunta si existe una lista donde pueda ver las maquinas que crean los paquetes dholbach responde que si, y le pasa el link https://launchpad.net/builders/ dholbach tambien agradece la avalancha de preguntas =) asegura que aunque sus dedos le duelen, aun no ve sangre, asi que cree seguro continuar miles de aplicaciones, billones de lineas de codigo, cientos de colaboradores, requieren mucha comunicacion y planeacion para mantener altos niveles de calidad asi que al comienzo de cada ciclo, se organiza el Ubuntu developer Summit, donde tanto desarrolladores como contribuiores se reunen para hablar sobre las caracteristicas de la siguiente version de Ubuntu cada idea se discute, y se toman anotaciones sobre la informacion requerida para implementarla, tambien se toman anotaciones de los cambios que se necesitan hacer en otros lugares, y del para probar las nuevas caracteristicas, entre otras cosas todo esto se hace en un ambiente abierto y transparente, asi que incluso cuando no se pueda asistir en persona, siempre se puede participar en linea, escuchar los streamcast, hablar con los asistentes y suscribirse a la lista de modificaciones y especificaciones de cada tema, de esta forma, siempre se pueden mantener al dia las personas interesadas como podran ver en: https://uds.ubuntu.com/ el siguiente UDS se realizara en Copenhage, si estaran por ahi, no duden en darse una vuelta como cada una de las modificaciones no pueden discutirse en una sesion, especialmente para los cambios que requieran modificaciones en otros proyectos las personas involucradas en Ubuntu permanecen en contacto entre ellas. La mayoria de los equipos o proyectos utilizan listas dedicadas de correo electronico, para evitar leer cosas no relacionadas a las caracteristicas que les interesan para una comunicacion mas rapida, tambien suelen usar el IRC (internet relay chat). Todas las discusiones suelen ser publicas los reportes de bugs, tambien suelen ser un medio de comunicacion, cada vez que se encuentra un defecto en un programa, o en alguna parte de la infraestructura de ubuntu, se crean reportes asi toda la informacion necesaria sobre determinado problema, puede concentrarse en un solo lugar, y actualizarse cuando sea conveniente la mayoria del software incluido en Ubuntu, no es escrito por los propios desarrolladores de la distribucion, la mayoria son hechos por otros programadores e integrados en Ubuntu a estos programas se les conoce como proyectos 'upstream', se llaman asi, porque su codigo fluye hacia Ubuntu, donde nosotros *solo* lo integramos la relacion que existe entre estos proyectos upstream y Ubuntu es muy importante, no solo Ubuntu se beneficia con su codigo, los proyectos generalmente obtienen mas usuarios, reportes y parches desde la distribucion el proyecto upstream mas importante de Ubuntu, es Debian, Debian es la distribucion en la cual esta basado Ubuntu, y muchas de las decisiones de diseño que afectan la infraestructura de empaquetamiento son hechas ahi tradicionalmente, Debian tiene mantenedores para cada paquete en su distribucion, otras veces son equipos los que se encargan de un subconjunto de paquetes. En Ubuntu tambien existen equipos que estan interesados en cierta cantidad de paquetes, y naturalmente, cada desarrollador puede tener una area de especializacion, sin embargo, como medio de participacion (y derechos para modificar paquetes), el sistema esta abierto para cualquier que demuestre suficiente habilidad y ganas de colaborar average_drifter menciona que hace poco obtuvo una copia de Htop 1.0.1 de github e hizo un parche, que su parche fue aceptado e integrado junto otros cambios que hizo el autor, siendo asi, se pregunta como pueden llegar esos cambios a Ubuntu?, htop es una programa de monitoreo de procesos muy parecido a top dholbach dice que eso es justo de lo que iba a hablar a continuacion NickE pregunta si launchpad puede usarse para organizar un proyecto, o si eso solo aplica para proyectos en upstream? dholbach responde que las personas pueden seleccionar Launchpad como el sitio que se hara cargo de la administracion del codigo, del mantenimiento de las plantillas de traduccion o del soporte tecnico sin embargo, aun cuando se decidiera usar otra plataforma para mantener el codigo, launchpad se puede configurar como repositorio espejo, para correr compilaciones diarias, entre otras cosas raju ha preguntado sobre las opciones para integrarse a un proyecto en Ubuntu dholbach contesta que el siempre recomienda hechar un vistazo en la lista de bugs, y preguntar por algunos sencillos para comenzar a trabajar en ellos afortunadamente mañana mismo a las 17:00 UTC, se tendra una charlas, sobre como arreglar estos bugs en Ubuntu ok, como veo que hay mucho interes en corregir problemas, y agregas cosas a Ubuntu, hablaremos sobre ello un momento incorporar un cambio en Ubuntu, no es tan dificil como pueda parecer al comienzo, no solo se de una experiencia de la cual se aprendera, tambien sobre solucionar y compartir la solucion con millones de usuarios el desarrollo de software libre se construye en un mundo distribuido en diferentes objetivos por ejemplo, puede darse el caso de que determinado proyecto upstream este interesado en trabajar en cierta caracteristica, mientras que Ubuntu, tal vez por el corto ciclo de desarrollo, prefiera incorporar una version super estable con algunos parches que solucionen problemas criticos este es el motivo por el cual usamos las palabras 'desarrollo distribuido', las modificaciones se hacen en diferentes ramas, que se van fusionando en la rama principal, despues suficiente discusion y una revision del codigo para el ejemplo anterior, Ubuntu incorporaria la version estable de ese programa, enviaria los parches criticos a upstream, y la proxima version en desarrollo de la aplicacion se agregaria a la siguiente version de Ubuntu, esto seria la forma mas justa de obtener una situacion donde todos ganaran un poco mas especifico: para solucionar un bug en Ubuntu, necesitaran el codigo fuente del programa, trabajar en el parche, documentarlo de tal manera que sea facil de leer tanto a otros desarrolladores como a los usuarios, compilar el paquete, y probar que funciona despues de verificar que funciona, se puede proponer el cambio, para que sea agregado a la version en desarrollo de Ubuntu, una vez que se haga eso, un desarrollador aprobado revisara el parche y si no encuentra problemas, lo integrara a Ubuntu si eso los hace sentirse curiosos, genial!, dentro de poco les dare algunos links para que aprendan mas al respecto, los mecanismos para solucionar un bug son siempre los mismos, asi que aprenderan a hacerlo muy rapido. Algunas veces puede que se encuentren con problemas mas dificiles de solucionar, sin embargo siempre habra personas que deseen ayudarlos =) raju pregunta como es que un usuario novato puede identificar la complejidad de un bug, y determinar si es facil o dificil de solucionar dholbach responde, que no los reportes no son faciles de identificar, y que algunas veces seguramente les pasara que inicien con un bug que creyeron facil, y al final se pasen horas trabajando en el eso le pasa todo el tiempo :) la buena noticia, es que ya hemos hecho el trabajo duro y seleccionado algunos reportes que son faciles de arreglar, sobre eso y mas les estara hablando Stefano en la sesion de mañana cuando intenten solucionar un problema, es una buena idea verificar si en el proyecto original ya esta el bug (y si ya esta arreglado), si no es asi, traten de poner lo mejor de si, para lograr que se resuelva cuando se intenta solucionar un error, algunas veces puede tomar pasos extra, como portar el parche a versiones anteriores de Ubuntu, o enviar la modificacion al proyecto original lo mas importante a la hr de introducirse en el desarrollo de Ubuntu es tener una mentalidad de 'hacer funcionar las cosas de nuevo', poder leer la documentacion, no tener miedo de hacer preguntas, saber jugar en equipo y tener cierta simpatia por el trabajo detectivesco prashanth pregunta si existe una lista de proyectos Upstreams de Ubuntu dholbach dice que es una excelente pregunta y que si desea conocer algun detalle sobre cualquier programa, puede ir a https://launchpad.net/ubuntu/+source/gedit (aqui, para gedit) y a https://launchpad.net/gedit geekette86 dice que le gustaria conocer mas sobre apport-retrace dholbach responde que apport-retrace es una excelente herramienta, y que lo que hace es que cuando un programa falla y se cierra por si mismo, genera un archivo core dump, donde se guardan los datos y variables que contenia el programa, aport-retrace toma ese archivo, y genera un archivo que es entendible por personas, en ese archivo se pueden visualizar todos los datos internos del programa, funciones, numero de linea donde ocurrio el problema, las variables que se usaban y su contenido, entre otras cosas dholbach pone https://wiki.ubuntu.com/DebuggingProgramCrash y sugiere que se lea en caso de querer saber mas sobre el tema Henrich pregunta sobre lo que pasa cuando un bug se encuentra tambien en upstream (por ejemplo en Debian), se reporta en su bugtracker?, si no es asi, porque? dholbach responde que si, en el caso de que estes seguro que un problema se encuentra tambien ahi, y que no fue provocado por algun cambio especifico de Ubuntu neoteric pregunta que pasa cuando un proyecto que tiene un repositorio espejo en launchpad recibe e integra un parche en launchpad?, este se envia automaticamente al proyecto original? dholbach responde que lamentablmente launchpad no soporta el envio de parches automaticamente, asi que el proceso lo tiene que hacer una persona raju pide que se le clarifique lo que se quiere decir con: "es una buena idea verificar si el problema (y una solucion) se conoce en Upstream, de lo contrario, trabajar para llegar a un concenso" dholbach responde tomando un ejemplo supongamos que encuentras un problema en gedit (se cierra solo por alguna razon) lo primero que tendrias que hacer es ver si existe una version en su pagina oficial que ya no tenga ese problema, si no encuentras pistas que te lo aclaren, entonces tendrias que revisar los mensajes de su repositorio (llamados commits) para ver si ahi encuentras la informacion si tampoco encuentras nada, tendrias que ir al bugtrack del proyecto (en este caso de gedit) y ver si al menos el bug ha sido reportado y tambien verificar si alguien esta trabajando en la solucion si ese es el caso, puedes ayudar a probar las soluciones, y agregar comentarios utiles, por ejemplo datos que no conocian si no existe reporte alguno, entonces tendras que generarlo, anexando toda la informacion que hayas encontrado hasta el momento eklok pregunta sobre la diferencia del sistema de empaquetamiento en Ubuntu, y el sistema de distribucion de software en Windows, siempre se ha preguntado porque las personas en Linux y en Ubuntu, deciden empaquetar los programas dholbach responde que una de las ventajas de un sistema de empaquetamiento, es que los desarrolladores de Ubuntu tienen control sobre lo que esta en al distribucion, si existe software que no es lo suficiente maduro, pueden evitar ponerlo, o usar versiones del programa que si lo sean, tambien es mas facil integrar el sistema, porque tienen el codigo fuente de todos los programas ademas de eso, pueden encontrar problemas de seguridad mas facilmente, y se simplifica el mantenimiento para los usuarios, solo tienen que aplicar una actualizacion, en lugar de preocuparse por las actualizaciones de 64325823 programas diferentes si me preguntas, es lo mejor que han creado, desde que inventaron el pan para hacer sandwiches ziviani pregunta sobre los proximos objetivos de Ubuntu, dados los enormes esfuerzos en Unity para mejorar la experiencia de los usuarios, cree que Ubuntu se esta enfocando un poco mas en UX. Es esta area, el area donde se estan concentrando los desarrolladores? dholbach responde que hay mucho interes en el area de UX, pero que no es la unica, existen varios equipos, algunos de los cuales se concentran en tener una version estable para servidores, o para asegurarse que Ubuntu funciona en toda clase de dispositivos, etc. agrega que https://wiki.ubuntu.com/Teams puede ayudar para ver el area de concentracion de cada equipo, y como involucrase exodus pregunta si se ha pensado en hacer eventos utilizando hangout o algun servicio similar de streaming dholbach responde que si, y que de hecho ya se han hecho algunos, el plan es que se sigan haciendo, sugiere seguir la cuenta de @ubuntudev en twitter, identi.ca, google+ y facebook para enterarse de los proximos eventos nja pregunta porque no utilizaron g+ hangout para esta sesion dholbach responde que en la siguiente sesion, habran comandos que podran copiar / pegar facilmente del irc, pero que esto no seria tan facil de hacer a partir de google+ hangout, agrega que probablemente en el futuro se hagan mas videos otro punto de interes, es que algunas personas que trabajan podrian no ser capaces de ver videos, pero si leer logs de irc, ademas de que puede buscarse cierta parte en los logs aun asi, es conciente que un video puede ser mas personal y atraer a mas personas, que una sesion basada en texto luisalvarado pregunta sobre las herramientas que recomienda para empezar a trabajar con bugs dholbach responde que se hablara mas sobre ello en la siguiente y en la sesion de estefano (mañana) eso es todo, regresare dentro de un momento para interpretar la ultima sesion del dia de hoy, mientras tanto subire los logs a la wiki, https://wiki.ubuntu.com/SemanaDesarrollador