Hola, On Tue, 2005-12-20 at 13:58 -0300, Juan Carlos Inostroza wrote: > On Tue, 2005-12-20 at 17:01 +0100, Claudio Saavedra wrote: > [...] > > > > Usando CVS; Construyendo con JHBuild; Resolviendo problemas de > > dependencias; Construyendo un escritorio en paralelo al incluído en la > > distribución; Iniciando sesión en este escritorio, etc. > > Yo podria aportar con Garnome. Tengo algo de experiencia en ese > cachibache :)
La idea es ayudar a la gente interesada en contribuir con el código. La gente interesada en contribuir con el código, debe tener el código que se encuentra en desarrollo. Dicho código está en el CVS. Garnome construye GNOME desde los paquetes estables, no desde el CVS. > > > Dia 2: Cacería de bugs y manos al código. > > ----------------------------------------- > > > > Bug triagging; Reportando nuevos bugs; Creando e interpretando > > backtraces; Corrigiendo bugs; Creación de parches; ChangeLogs, etc. > > Eso es un poco mas arriesgado, ya que tendrias que enseñar > - a usar strace para posibles errores > - a usar GDB en un ambiente controlado, primero > - a entender el backtrace > - a corregirlo :) Alto ahí. ¿enseñar a corregir un bug? Ve mi respuesta más abajo. > > Si. O bien, tirar el ultimo release "estable" o bien el CVS. No se, yo > me quedaria con la version estable antes. > > Ahi podriamos incluso aplicar el cambio entre el ultimo release y la > version de CVS, apoyandonos en parches que hayan salido. > > Digo, por que improvisar, en esa area, es complicado... > ¿Improvisar? Si entiendo correctamente, tu perspectiva va por el lado de enseñar algo conocido y dominado. Yo no creo que sea posible en un ambiente tan dinámico como GNOME (si quieres enseñar GTK+ o algún lenguaje de programación, probablemente sí, pero estamos hablando de otra cosa). La idea de los gnome-love days es que los hackers *guien* con su experiencia a quienes estén interesados en resolver problemas por si mismos, pero no sepan como enfrentar ciertos problemas propios de la metodología de trabajo. La idea de resolver bugs sencillos, es que estos sean simplemente una excusa para que los protohackers se familiarizen con la iteración que esto implica (actualizar el código, reproducir el bug, analizarlo como corresponda, discutir posibles soluciones, generar una solución, generar un parche, publicarlo, aceptar el feedback, mejorar el parche, iterar). Por último, si estos bugs están abiertos, no sólo estamos guiando a posibles nuevos contribuyentes: estamos contribuyendo con el código de GNOME. Algunas lecturas interesantes sobre este tema: Guía de Nat Friedman para como convertirse en Hacker: http://www.nat.org/2005/september/#How-to-become-a-hacker Anuncio original de Fer sobre los GNOME Love days. http://mail.gnome.org/archives/gnome-hackers/2004-February/msg00089.html Claudio -- Claudio Saavedra <[EMAIL PROTECTED]>
