| chilicuil | necesitaran una llave gpg y ssh para hacer esto, deberan leer la documentacion para conocer los por menores | 01:03 |
|---|---|---|
| chilicuil | https://help.launchpad.net/YourAccount/ImportingYourPGPKey | 01:03 |
| chilicuil | https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair | 01:03 |
| chilicuil | sin embargo, de nuevo, supongamos que ya lo han hecho, y que tienen su repositorio PPA | 01:03 |
| chilicuil | $ quickly share --ppa mterry/testing | 01:04 |
| chilicuil | empaquetara su programa y lo subira a su repositorio de pruebas | 01:04 |
| chilicuil | 'quickly share' le pondra un nombre como 0.1public1 al paquete de prueba | 01:05 |
| chilicuil | no es un bonito nombre, pero esto es asi, porque 'quickly share' se supone que se usa para compartir varias versiones previas de los programas | 01:10 |
| chilicuil | cuando su programa este listo para produccion, pueden utilizar $ quickly release | 01:10 |
| chilicuil | lo que subira su paquete, y le asignara una version mas elegante, como 12.08 | 01:11 |
| chilicuil | nja pregunta que editor recomendaria para programar en python | 01:12 |
| chilicuil | mterry responde que como es ludita, es decir, que no le agradan mucho las maquinas, prefiere usar un editor simple como gedit | 01:15 |
| chilicuil | y aclara que tal vez el no sea la mejor personas para responder esa pregunta | 01:15 |
| chilicuil | recomienda que escuche las respuestas que el resto de las personas le sugieran en el canal de discusion | 01:16 |
| chilicuil | regresando a la charla | 01:16 |
| chilicuil | una vez que he hablado un poco de 'share' y de 'release' | 01:17 |
| chilicuil | hablare de 'submitubuntu' | 01:18 |
| chilicuil | supongan que han seguido mejorando su aplicacion, y ahora consideran que es perfecta | 01:18 |
| chilicuil | tal vez querran enviarla al centro de software de Ubuntu | 01:19 |
| chilicuil | en ese caso pueden utilizar el comando | 01:19 |
| chilicuil | $ quickly submitubuntu | 01:19 |
| chilicuil | lo que tambien subiera esa version a su ppa | 01:19 |
| chilicuil | pero que ademas hara algunos cambios en el empaquetamiento que son necesarios para los programas que quieren ser parte del repositorio -extra | 01:20 |
| chilicuil | si quieren probar el paquete que se genera con el comando 'submitubuntu', pueden correr quickly de esta forma: | 01:21 |
| chilicuil | $ quickly package --extras | 01:22 |
| chilicuil | lo que hace basicamente quickly es poner los datos de su programa en /opt, en lugar de mezclarlos con el resto del sistema (/usr/bin, /usr/share, etc) | 01:23 |
| chilicuil | green7 pregunta si el recomendaria usar quickly en lugar de pygtk | 01:24 |
| chilicuil | mterry responde que si la aplicacion que esta haciendo la esta haciendo para compartirla en ubuntu, si | 01:24 |
| chilicuil | agrega que quickly solo es una interfaz alrededor de pygtk | 01:24 |
| chilicuil | que ayuda con el empaquetamiento y la integracion, ademas de tener cierta cantidad de magia como la que existe entre Glade y su codigo | 01:25 |
| chilicuil | ironhalik pregunta sobre la compatibilidad de quickly con las versiones anteriores de Ubuntu | 01:26 |
| chilicuil | mterry responde que no deberian existir muchos problemas | 01:27 |
| chilicuil | quickly agrega cierta cantidad de codigo en las aplicaciones (por ejemplo, el directorio test_project_lib) | 01:27 |
| chilicuil | que bien podrian quedar iguales en caso de que se quisiera migrar alguna aplicacion hecha con quickly para versiones anteriores | 01:30 |
| chilicuil | el unico que problema que podria haber, seria con las dependencias | 01:30 |
| chilicuil | por ejemplo, si su programa dependiera de otros que no existen, o que son mas nuevos de los que existen en la version de la distribucion a la cual se quiere migrar | 01:31 |
| chilicuil | sin embargo quickly por si mismo deberia funcionar bien, la version del 12.04 usa introspeccion de gobjetos para los bindings en GTK/python | 01:47 |
| chilicuil | no se que tan estable sea eso, supongo que es muy probable que no funcione en 10.4 | 01:48 |
| chilicuil | aunque deberia en Ubuntu 11.10 al menos | 01:50 |
| chilicuil | gigix pregunta si quickly hace dependiente un programa de Ubuntu | 01:50 |
| chilicuil | mterry responde que no | 01:50 |
| chilicuil | que quickly solo ofrece atajos para hacer el proceso de desarrollo en Ubuntu mas facil | 01:51 |
| chilicuil | por ejemplo, ayudando a crear paquetes .deb de los programas, o ayudando a distribuirlos (subiendolos a un ppa) | 01:51 |
| chilicuil | sin embargo, el propio codigo de la aplicacion no depende de alguna caracteristica de Ubuntu | 01:51 |
| chilicuil | FlowRiser pregunta por tutoriales de GTK | 01:52 |
| chilicuil | mterry recomienda http://developer.gnome.org/ | 01:53 |
| chilicuil | http://developer.gnome.org/gtk3/stable/ (resumen del api) | 01:54 |
| chilicuil | y http://developer.ubuntu.com/resources/ | 01:54 |
| chilicuil | marcosb pregunta si hay planes para agregar plantillas para Ruby | 01:54 |
| chilicuil | mterry responde que no | 01:55 |
| chilicuil | ben72 pregunta si hay alguna forma de forzar a quickly para que funcione con python 3, y agrega que en la sesion de ayer les enseñaron que debe usarlo en lugar de python2 | 01:56 |
| chilicuil | mterry felicita a ben72 por la excelente pregunta | 01:56 |
| chilicuil | y admite que quickly tiene una importante falla en esto | 01:57 |
| chilicuil | esta de acuerdo en que las nuevas aplicaciones deberian crearse con python 3 | 01:57 |
| chilicuil | sin embargo, aun no hay podido migrar quickly para que use python 3 | 01:57 |
| chilicuil | especialmente con el empaquetado | 01:58 |
| chilicuil | asi que lo que recomienda es utilizar quickly para hacer una aplicacion | 01:58 |
| chilicuil | y que posteriormente se migre a python 3 | 01:59 |
| chilicuil | (lo cual deberia ser muy facil) | 02:00 |
| chilicuil | sin embargo, sin hacen esto, ya no podran correr 'quickly package', 'share', 'release' o 'submitubuntu' | 02:01 |
| chilicuil | =( | 02:01 |
| chilicuil | sin embargo pueden tomar el paquete en python 2 que genera quickly, modificar el directorio /debian, migrar sus programa a python 3, y hacer que vuelva a funcionar el empaquetamiento | 02:04 |
| chilicuil | al menos no tendran que comenzar de 0 | 02:04 |
| chilicuil | quickly tiene otras caracteristicas | 02:15 |
| chilicuil | por ejemplo 'quickly save' | 02:15 |
| chilicuil | este comando guardara sus cambios en un sistema de control de versiones llamado bzr (bazaar) | 02:16 |
| chilicuil | sera como guardar su avance cada vez que hagan cambios que se relacionen entre si | 02:17 |
| chilicuil | tambien pueden usar bzr directamente (por ejemplo $ bzr diff) para ver los cambios que han estado haciendo, etc | 02:18 |
| chilicuil | bzr es muy bueno, y esta integrado con Launchpad, por ejemplo, podrian hacer $ bzr push lp:~mterry/+junk/test-project | 02:19 |
| chilicuil | y eso enviaria su codigo al sitio (en mi cuenta, claro, para su caso, sera otra diferente) | 02:19 |
| chilicuil | +junk es un truco de launchpad, de esta manera pueden subir archivos sin tener que definir un proyecto | 02:22 |
| chilicuil | si ya han definido un nombre de proyecto en launchpad, entonces pueden usarlo | 02:22 |
| chilicuil | en fin, todo eso, son cosas de launchpad y no quickly | 02:22 |
| chilicuil | solo queria mencionar el comando $ quickly save | 02:23 |
| chilicuil | otro buen truco es $ quickly add dialog new-dialog | 02:23 |
| chilicuil | supongamos que quieren agregar un dialogo para guardar, o una ventana de error. En ese caso, quickly les ayuda un poco | 02:24 |
| chilicuil | creara el codigo y lo agregara a glade (aunque tendran que cerrar Glade y volverlo a abrir con $ quickly design | 02:25 |
| chilicuil | tambien tendran que correr de nuevo $ quickly edit para abrir los archivos recien creados | 02:26 |
| chilicuil | despues de esto, veran el codigo generado, y la nueva interfaz en glade | 02:26 |
| chilicuil | por lo que solo tendran que importarlo en su ventana principal con "from nombre_proyecto.DialogName import DialogName" | 02:27 |
| chilicuil | e instanciarlo con "d = DialogName()" | 02:27 |
| chilicuil | pueden correr $ quickly help para ver todos los comandos disponibles, y la ayuda particular de cada uno, como con $ quickly help save | 02:28 |
| chilicuil | skizobass pregunta, cuando se crea un nuevo dialogo con Quickly, como se separa ese archivo del script principal? | 02:30 |
| chilicuil | mterry responde que quickly creara un nuevo archivo en python (en test_project/ por ejemplo) | 02:30 |
| chilicuil | asi que si se utiliza $ quickly add dialog hello | 02:31 |
| chilicuil | se creara un archivo en test_project/HelloDialog.py | 02:31 |
| chilicuil | (espero que le haya atinado al nombre) | 02:31 |
| chilicuil | nja pregunta si hay algo parecido a .toString() en python | 02:31 |
| chilicuil | mterry responde que si, str() | 02:32 |
| chilicuil | y que se usa de la siguiente manera, si se tiene un objeto 'o' | 02:32 |
| chilicuil | se puede hacer str(o) para obtener una cadena | 02:32 |
| chilicuil | skizobass pregunta si quickly separa el codigo de cada nuevo dialogo | 02:34 |
| chilicuil | mterry responde que si, siempre y cuando se use el comando $ quickly add dialog para generarlo | 02:34 |
| chilicuil | y agrega que los programadores no tienen porque seguir esa forma de trabajo | 02:35 |
| chilicuil | que pueden organizar el codigo como mejor les parezca | 02:36 |
| chilicuil | pero cuando quickly tenga que generar codigo, lo hara asi | 02:36 |
| chilicuil | vale, parece que casi se me ha acabado el tiempo | 02:36 |
| chilicuil | se que esta introduccion fue muy simple, pero espero que ahora tengan una mejor idea de lo que es quickly | 02:37 |
| chilicuil | y por que querrian usarlo | 02:37 |
| chilicuil | de nuevo, recomiendo que utilicen los comandos "quickly help" y "quickly tutorial" para aprender a usarlo por su cuenta | 02:37 |
| chilicuil | http://developer.ubuntu.com/resources/app-developer-cookbook/all-recipes/ tambien les puede ser de ayuda | 02:38 |
| chilicuil | al igual que http://developer.ubuntu.com/resources | 02:38 |
| chilicuil | nja pregunta si en python es posible usar un constructor con diferentes argumentos | 02:40 |
| chilicuil | mterry responde que si y no | 02:40 |
| chilicuil | es decir, siempre se usa el mismo metodo | 02:40 |
| chilicuil | pero puedes tener argumentos que sean opcionales, por ejemplo __init__(option1=None, option2=None) | 02:41 |
| chilicuil | mterry agradece a todos por sus preguntas, y finaliza su sesion | 02:43 |
| Cayo | hola buenas tardes a todos! | 13:47 |
| chilicuil | hola Cayo, bienvenido | 13:47 |
| chilicuil | dentro de poco comenzara el tercer dia del desarrollador, asegurate de tambien entrar a #ubuntu-classroom y #ubuntu-classroom-chat | 13:48 |
| Cayo | ah que bueno | 13:49 |
| Cayo | y como fue los dos otros dias, estaba sin internet, y no pudo participar :( | 13:51 |
| chilicuil | pues bien, el primer dia fueron introducciones, ayer fueron temas de programacion, hubo buena participacion, en general hemos podido interpretar mas de la mitad de las charlas | 13:53 |
| chilicuil | si te lo perdiste puedes hecharle un vistazo a los logs en español e ingles en https://wiki.ubuntu.com/SemanaDesarrollador | 13:54 |
| Cayo | muchas gracias! | 14:17 |
| chilicuil | ha comenzado el ultimo dia de la semana del desarrollador | 14:56 |
| chilicuil | Daniel Holbach recuerda que el canal #ubuntu-classroom sera usado unicamente para la sesion, y #ubuntu-classroom-chat para la discusion y para hacer preguntas | 14:58 |
| chilicuil | si tienen alguna pueden hacerla usando el prefijo QUESTION | 14:58 |
| chilicuil | ejemplo QUESTION: Is it true some of your teammates can discuss Metallica albums for hours? | 14:58 |
| chilicuil | las preguntas van en ingles, si tienen algun problema para formularla, pueden escribirla aqui, y con gusto les ayudare a plantearla | 14:58 |
| chilicuil | comenzare con la interpretacion | 15:03 |
| GridCube | Hola | 15:03 |
| chilicuil | buenos dias, mi nombre es David Planella y trabajo en Canonical como parte del equipo que se encarga de administrar la comunidad (Community), sin embargo hoy vengo con las intenciones de hablarles sobre programacion en Ubuntu | 15:04 |
| chilicuil | hola GridCube, bienvenido | 15:04 |
| chilicuil | esta sesion, sera un poco diferente de las que se han dado hasta el momento | 15:05 |
| chilicuil | voy a hablar sobre como crear aplicaciones para Ubuntu | 15:05 |
| chilicuil | en lugar de mantenerlas o trabajar en la plataforma en si | 15:06 |
| chilicuil | las dos son igualmente de entretenidas, asi que sientanse libres de escoger entre cualqueira de las dos | 15:06 |
| chilicuil | siendo asi durante la siguiente media hr, hablare sobre como enviar sus aplicaciones a Ubuntu | 15:07 |
| chilicuil | para que puedan aparecer en el Centro de Software y puedan ser distribuidas a millones de personas | 15:07 |
| chilicuil | sin embargo, no solo sera una presentacion, me gustaria que todos participaran e hicieran sus preguntas al final de la sesion | 15:08 |
| chilicuil | recuerdenlas que para hacerlas deben usar el prefijo QUESTION y hacerlas en #ubuntu-classroom-chat | 15:08 |
| chilicuil | durante la charla me estare refiriendo constante a varios lugares del sitio de desarrollo de Ubuntu | 15:09 |
| chilicuil | http://developer.ubuntu.com | 15:09 |
| chilicuil | comencemos | 15:09 |
| chilicuil | Creando su aplicacion | 15:09 |
| chilicuil | ======================= | 15:09 |
| chilicuil | bueno, el primer paso es un tanto obvio, primero tendran que crear una aplicacion | 15:10 |
| chilicuil | esto es basicamente ese momento maravilloso en que convierten una buena idea en un programa funcional | 15:10 |
| chilicuil | no hablare mucho de esta parte, porque esta mas alla de esta sesion | 15:10 |
| chilicuil | sin embargo, dare un par te tips para los que les interese | 15:11 |
| chilicuil | el primer tip, es que usen las aplicaciones que ya estan en los repositorios | 15:11 |
| chilicuil | muchos de estas aplicaciones son muy poderosas y son suficientemente flexibles | 15:12 |
| chilicuil | asi que ademas de ayudarles a desarrollar sus programas, les enseñaran buenas practicas de programacion | 15:12 |
| chilicuil | si eso no fuese suficiente, es software libre (y tambien gratis) | 15:13 |
| chilicuil | pueden ver una guia de estas aplicaciones en | 15:13 |
| chilicuil | http://developer.ubuntu.com/get-started/quickly-workflow/ | 15:13 |
| chilicuil | quickly es el nombre del proyecto, que pone todas estas herramientas en un solo lugar | 15:14 |
| chilicuil | si queiren saber mas sobre el tema, mterry dio una charla sobre ello durante esta semana del desarrollador | 15:14 |
| chilicuil | asi que pueden darle un vistazo en los logs | 15:14 |
| chilicuil | tambien pueden ver una introduccion en el siguiente video | 15:15 |
| chilicuil | http://developer.ubuntu.com/get-started/ | 15:15 |
| chilicuil | Que tipo de aplicaciones se aceptan | 15:15 |
| chilicuil | ===================================== | 15:15 |
| chilicuil | hay miles de aplicaciones en los repositorios de Ubuntu, varias de ellas llegan de diferentes formas | 15:16 |
| chilicuil | y se podrian clasificar en diferentes tipos, algunos son programas del sistema, otras aplicaciones desarrolladas por Ubuntu, etc | 15:16 |
| chilicuil | sin embargo todas ellas se someten a estrictas reglas de seguridad, y calidad, ademas de ser software libre | 15:17 |
| chilicuil | para diferencias estas aplicaciones de otras utilizare el termino "proceso de aplicaciones para desarrolladores"/"the app developer process" | 15:18 |
| chilicuil | para responder algunas preguntas, basicamente existen 3 tipos de aplicaciones que pueden ser aceptadas a traves de este proceso | 15:19 |
| chilicuil | * aplicaciones comerciales | 15:19 |
| chilicuil | * aplicaciones con licencia comercial, pero que son gratis | 15:19 |
| chilicuil | * aplicaciones libres | 15:19 |
| chilicuil | pueden notar como ademas de aceptar software libre, fomentamos el software comercial, esto es para dar darles oportunidad a los autores de estos programas y para poder hacer algo de dinero para Canonical | 15:21 |
| chilicuil | 1.- Como enviar tu aplicacion | 15:21 |
| chilicuil | =============================== | 15:21 |
| chilicuil | bien, cuando llegues a este punto ya tendras un programa y querras compartirlo con el resto del mundo | 15:22 |
| chilicuil | la buena noticia, es que el proceso que hemos creado es facil de usar y lo puedes hacer desde un navegador, asi que puedes enviarlo y estar al pendiente del estado de tu aplicacion todo el tiempo desde el sitio web | 15:23 |
| chilicuil | https://myapps.developer.ubuntu.com | 15:23 |
| chilicuil | notaran que ha sido hecho facil de usar a proposito, lo unico que necesitan es crear una cuenta para poder comenzar | 15:24 |
| chilicuil | pueden registrarse gratis y en un par de minutos, el proceso esta basado en el sistema de login unico de Ubuntu (SSO), si ya tienen una cuenta en otros servicios relacionados con ubuntu, entonces sera aun mas rapido | 15:25 |
| chilicuil | hubo un netsplit, asi que perdi parte del log de la segunda charla, seguire interpretando en la tercera: "Adding test cases with UTAH" | 15:46 |
| chilicuil | comenzare con la intepretacion, gema aprovecha para saludar a todos | 16:01 |
| chilicuil | hola, mi nombre es Gema Gomez-Solano y trabajo para el equipo de calidad (QA team) en Canonical | 16:02 |
| chilicuil | voy hablarles sobre UTAH, o el sistema de automatizacion de pruebas de ubuntu (Ubuntu Test Automation Harness) | 16:03 |
| chilicuil | basicamente es una herramientas que hicimos para empezar a tener un orden en las pruebas que estabamos haciendo | 16:03 |
| chilicuil | asi que nos gustaria compartirla en caso de que otras personas tengan el mismo problema | 16:04 |
| chilicuil | UTAH se supone que es un programa para ayudar durante todo el proceso de pruebas | 16:05 |
| chilicuil | la pagina del proyecto esta en https://launchpad.net/utah | 16:05 |
| chilicuil | en fin, comencemos por describirla con poco mas de detalle | 16:05 |
| chilicuil | el proceso general es tomar una imagen iso de algun lugar, instalar la imagen en una maquina real/virtual y devolver los resultados | 16:07 |
| chilicuil | antes de tener esta herramientas estabamos trabajando con varias cosas que requerian modificarse a detalle para resolver problemas muy particulares | 16:07 |
| chilicuil | asi que teniamos que hacer pruebas de imagenes iso, para hacer pruebas de posibles regresiones del kernel, para verificar las actualizaciones... | 16:08 |
| chilicuil | y lo haciamos en maquinas virtuales de 32, 64 bits y arquitectura ARM | 16:08 |
| chilicuil | asi que tenias varios scripts, cada uno resolvia un problema especifico | 16:09 |
| chilicuil | esta situacion no era unica del equipo de pruebas (QA), lo mismo ocurrio en los equipos de desarrollo | 16:09 |
| chilicuil | existia mucho codigo que se estaba repitiendo en varios lugares | 16:10 |
| chilicuil | asi que empezamos a construir esta herramienta para unificar todo lo que estabamos haciendo | 16:10 |
| chilicuil | ahora las pruebas pueden hacerse en cualquier lenguaje y despues integradas en UTAH para que puedan correr como parte del sistema | 16:11 |
| === carlos is now known as Guest27302 | ||
| chilicuil | tambien se puede configurar para que corran determinadas pruebas a cierta hora, para eso usamos jenkins | 16:11 |
| chilicuil | pueden usar cron o cualquier otro sistema que les acomode para ese caso | 16:12 |
| chilicuil | esperamos que UTAH tambien nos ayude a reproducir bugs | 16:12 |
| chilicuil | hola Guest27302, en este canal se hace la interpretacion de #ubuntu-classroom, estamos hablando sobre automatizacion de pruebas de testing, si tienes alguna pregunta puedes hacerla en #ubuntu-classroom-chat, si tienes problemas con el Ingles, puedes hacerla aqui y la hare por ti alla =) | 16:13 |
| chilicuil | cada vez que encontremos un bug con este sistema, deberiamos ser capaz de enviarle un archivo con las instrucciones precisas a un desarrollar, y el podria reproducirlo | 16:14 |
| chilicuil | eso sin tener que preocuparse por la instalacion | 16:15 |
| chilicuil | intentamos hacer que todas las pruebas se automaticen | 16:15 |
| chilicuil | La estructura de pruebas en UTAH | 16:15 |
| Guest27302 | gracias soy nuevo en el mundo ubuntu, GNU/linux en general | 16:16 |
| chilicuil | las pruebas (cases) son la unidad mas pequeña de ejecucion en UTAH, ponemos cada una de estas pruebas en diferentes archivo, asi podemos escoger cualquier de ellos en dterminado momento, esto funciona incluso si el testcase recive parametros y llama a otros dependiendo de ello | 16:17 |
| chilicuil | los testcases pueden agregarse o quitarse, asi cada persona tiene control sobre su entorno | 16:18 |
| chilicuil | los testcases deben dejar el sistema en el mismo estado en el que lo recibieron, hemos llegado a esta politica despues de considerar que es una buena politica para evitar tener problemas con otros testcases | 16:19 |
| chilicuil | de esta forma tambien podemos hacer independiente el orden en el que se pueden correr las pruebas, ninguna depende de otra | 16:20 |
| chilicuil | los testcases tambien pueden agruparse en grupos | 16:20 |
| chilicuil | las suits de testcases son grupos de testcases cuya finalidad es probar cierta funcionalidad y que se mantienen en buen estado en su conjunto | 16:20 |
| chilicuil | por ejemplo, el grupo de pruebas sera mantenido por un desarrollar que tiene mucha experiencia en esa parte del proceso | 16:21 |
| chilicuil | tambien tenemos listas de pruebas, estas lista se aseguran de ejecutar un grupo de testcases al mismo tiempo | 16:22 |
| chilicuil | estas listas podrian ser diferentes entre digamos, ubuntu quantal y ubuntu precise, esto es porque puede ser que quieras probar diferentes cosas dependiendo de la distribucion | 16:23 |
| chilicuil | en fin, hemos hablado sobre como UTAH nos ayuda a probar las instalaciones de Ubuntu | 16:23 |
| chilicuil | asi como de que las pruebas de UTAH pueden ser hechas en cualquier lenguaje y devuelven errores en una forma estandard | 16:24 |
| chilicuil | UTAH analiza los logs que se generan en stderr y stdout (salidas estandard) | 16:24 |
| chilicuil | UTAH soporta reinicios, asi si una prueba necesita que el equipo se reinicie, UTAH lo hara y despues continuara donde se quedo | 16:25 |
| chilicuil | los testcases tienen tiempo de expiracion, los grupos de testcases tambien lo tienen, e incluso se puede definir un tiempo para todo el proceso | 16:26 |
| chilicuil | esto es especialmente importante cuando haces pruebas completas, a la mayoria de las personas no les gustaria que un servidor se quedara en el mismo estado durante mucho tiempo, solo porque una prueba ha fallado | 16:27 |
| chilicuil | las listas de pruebas (runlists) pueden escoger pruebas especificas de los grupos de pruebas | 16:27 |
| chilicuil | cual es el estado actual del sistema? | 16:28 |
| chilicuil | bueno, ya estamos usando UTAH para hacer pruebas en el tiempo de arranque de Ubuntu | 16:28 |
| Guest27302 | Felicitaciones por tu labor *chilicuil* | 16:28 |
| chilicuil | y empezamos a migrarlo al sistema de pruebas de ISO | 16:29 |
| chilicuil | no tienes porque, lo hago con mucho gusto, y ademas me ayuda a entender mejor los temas, no suelo ser bueno reteniendo cosas =), continuo | 16:29 |
| chilicuil | la parte mas dificil a la que nos hemos enfrentado al hacer esta migracion es decirdir como modificar la estructura de las pruebas, para que puedan agregarse facilmente en el futuro | 16:30 |
| chilicuil | tambien estamos trabajando para automatizar las pruebas en la arquitectura ARM | 16:31 |
| chilicuil | TheLordOfTime pregunta como puede obtener UTAH para empezar a usarlo | 16:31 |
| chilicuil | gema agradece la pregunta y agrega que la documentacion del proyecto se encuentra en http://utah.readthedocs.org/en/latest/index.html ahi encontrara esa informacion | 16:32 |
| chilicuil | agrega que tal vez tambien quiera inscribirse a la lista de correo para obtener noticias frescas https://lists.canonical.com/mailman/listinfo/ubuntu-utah-devel | 16:32 |
| chilicuil | o para preguntar en caso de que tenga problemas configurando el sistema | 16:32 |
| chilicuil | jsjgruber-l85-p pregunta si es posible usar UTAH para hacer pruebas en aplicaciones graficas | 16:33 |
| chilicuil | gema responde que es una buena pregunta, y que por el momento no es posible, pero que se esta trabajando en esa caracteristica | 16:33 |
| chilicuil | agrega que la razon por la por el momento no es posible es porque UTAH se conecta a la maquina donde hara las pruebas de forma remota a traves de ssh | 16:34 |
| chilicuil | siendo de esta forma, aun no se ponen de acuerdo como comenzar la sesion X para empezar a hacer las pruebas graficas desde ahi | 16:34 |
| chilicuil | sugiere una vez mas que se unan a la lista de correo si desean hacer sugerencias al sistema o si tienen cualquier otra pregunta | 16:35 |
| chilicuil | ahora hablara un poco mas sobre como hacer testing de una formas mas general | 16:35 |
| chilicuil | y eso no se limitara a UTAH | 16:35 |
| chilicuil | marcosb pregunta sobre sistemas de pruebas que puedan usarse en Linux | 16:36 |
| chilicuil | gema responde que ademas de UTAH en ubuntu tambien se tiene autopilot | 16:36 |
| chilicuil | Xpresser o checkbox, que se usa para hacer algunas pruebas manuales y certificaciones | 16:37 |
| chilicuil | gema dice que las preguntas pueden dirigirse directamente a #ubuntu-classroom | 16:39 |
| chilicuil | la sesion se tornara una mesa redonda =) | 16:39 |
| chilicuil | he preguntado si nicolas skaggs es parte de su equipo, o si los equipos estan divididos por funciones | 16:40 |
| chilicuil | gema ha respondido que el es el coordinador de las pruebas de testing de la comunidad, asi que trabajan con el en pruebas que benefician la parte abierta de Ubuntu | 16:41 |
| chilicuil | agrega que nick no es parte del equipo pero que se suelen comunicar con mucha frecuencia con el | 16:41 |
| chilicuil | tambien menciona que en canonical y con la ayuda de la comunidad se crean testcases que luego pueden ser usados por nosotros, los usuarios | 16:42 |
| chilicuil | he preguntado porque no habia escuchado del sistema UTAH en los correos que Nicolas envia con frecuencia en la lista de testing de la comunidad | 16:45 |
| chilicuil | y gema ha respondido que porque UTAH aun esta en fase de pruebas, sin embargo Nicolas pregunta por el casi todos los dias, asi que espera que pronto se pueda empezar a usar en 'produccion' | 16:45 |
| chilicuil | aun hay algunos minutos, si tienen alguna pregunta sientanse libre de hacerlas | 16:47 |
| chilicuil | todas son bienvenidas, no hay preguntas demasiado basicas | 16:47 |
| chilicuil | gema agrega que si alguien se siente curioso por ver los resultados de las pruebas actualeas, puede hechar un vistazo a https://jenkins.qa.ubuntu.com/ | 16:50 |
| chilicuil | y si alguien quiere participar, puede comenzar a hacerlo leyendo la wiki https://wiki.ubuntu.com/QATeam/ | 16:52 |
| chilicuil | gema se despide y sugiere que si alguien mas esta interesado entre a #ubuntu-testing | 16:59 |
| chilicuil | dentro de breve comenzara la sesion sobre webapps en Ubuntu, durante este ciclo ubuntu ha agregado caracteristicas al launcher que hacen que puedan correr gmail como si tratara de otra aplicacion, sobre ello ira la sesion | 17:02 |
| chilicuil | lamalex y alex-abreu seran los ponentes durante esta sesion | 17:04 |
| chilicuil | ambos son parte del equipo 'webapp' de canonical | 17:05 |
| chilicuil | comienzo la interpretacion ahora | 17:05 |
| chilicuil | Canonical desarrollo la idea de webapps para intentar cerrar el trecho que hay entre las aplicaciones web y las de escritorio | 17:06 |
| chilicuil | la diferencia a veces no es muy clara, y la unica barrera que hay entre ellas suele ser tecnologica | 17:06 |
| chilicuil | no somos los primeros en intentar esto claro esta, pero creemos que vale la pena intentarlo | 17:06 |
| chilicuil | hace poco rick spenser intento fusionar el desarrollo de aplicacion html5 con aplicaciones de escritorio, incluso hizo un demo, sin embargo aunque el resultado es bueno, deja mucho a desear | 17:08 |
| chilicuil | lo que estamos intentando hacer es integrar las aplicaciones web a traves de un api en javascript que los autores de las aplicaciones web pueden usar para hacer que su programa se comporte como si estuviera hecho para el escritorio | 17:11 |
| chilicuil | la idea es que con esa API se exponga a otros scripts para que se pueda hacer la integracion desde varios puntos | 17:12 |
| chilicuil | a traves de esta API, los scripts tendrian acceso a varias caracteristicas, como el menu de mensaje, el de sonido, el lanzador (con su icono, listas de acceso, etc) | 17:13 |
| chilicuil | tambien podrian tener acceso al dash (donde se pueden ir agragando acciones), arrastrar y soltar, cambio de ventanas (alt-tab), entre otras cosas en las que estamos pensando | 17:14 |
| chilicuil | hasta que llegue un punto en que la integracion se sienta bien | 17:15 |
| chilicuil | pensamos que la integracion se puede lograr de 2 formas basicamente | 17:15 |
| chilicuil | 1.- a traves del navegador (con firefox o chromium), si fuera asi tendrian un script asociado que integrara 'nativamente' las aplicacions con Ubuntu a traves del acceso directo a nuestra API | 17:20 |
| chilicuil | 2.- usando un lanzador (con un icono de la aplicacion) que iniciara un programa que ya sido integrado, esto iniciaria el navegador (el que usaran por defecto) en un modo especial "chromeless" | 17:22 |
| chilicuil | de esta forma se quitarian todos los elementos del navegador dejando unicamente la vista de las pestañas | 17:22 |
| chilicuil | el menu podria ser diseñado para abarcar un minimo (y en el futuro podria expanderse con comandos especificos de cada aplicacion web) | 17:23 |
| chilicuil | la idea de tener el navegador sin muchos elementos graficos es que se puedan acomodar varios tipos de aplicaciones web que esten relacionados (que pertenezcan a un mismo sitio web por ejemplo) | 17:26 |
| chilicuil | por ejemplo, google docs | 17:27 |
| chilicuil | todos tus documentos tendrian que abrirse en la misma ventana | 17:27 |
| chilicuil | y una vez que saliera de esa pagina se abriria otra ventana del navegador como si tratara de otra aplicacion | 17:27 |
| chilicuil | estamos muy emocionados que este trabajo ofrezca tantas oportunidades de colaboracion con la comunidad de Ubuntu | 17:28 |
| chilicuil | ahora que hemos descrito la idea, hablaremos un poco mas de como se integran los componentes y haremos un tutorial de como hacer un script para este sistema | 17:29 |
| chilicuil | esperamos que en este ultimo apartado sea el mas util para la comunidad, entre mas aplicaciones web sean integradas mejor sera su uso en Ubuntu | 17:31 |
| chilicuil | planeamos que el resultado de todo esto lo podamos sugerir en las charlas con las organizaciones de estandarizacion de las tecnologias web, lo que a futuro podria traer una mejor integracion multiplataforma, empezando con Ubuntu | 17:32 |
| chilicuil | comencemos con los scripts de usuario, este es codigo en javascript que integra una aplicacion web con ubuntu | 17:33 |
| chilicuil | hay de 2 tops, los scripts de usuario y los scripts nativos (userscripts/native) | 17:34 |
| chilicuil | un script de usuario es basicamente un script de greasemonkey, esa clase de scripts se injectan en el navegaddor y se ejecutan mientras la pagina se carga, se comportan como codigo javascript ordinario | 17:35 |
| chilicuil | ~estos son los que se instalan con el paquete unity-webapps | 17:35 |
| chilicuil | lo que hacen es analizar la estructura DOM y hacen varias llamadas al API de aplicaciones de web de Unity (http://developer.ubuntu.com/api/ubuntu-12.04/javascript/unity-web-api-reference.html) esto provoca que se puedan intercambiar mensajes con el lanzador, con el HUD, con el menu de mensajes entre otros | 17:37 |
| chilicuil | estos son los puntos mas importantes, el resto del stack se trata de modificar algunos bits para que funcione sin problemas | 17:37 |
| chilicuil | esto funciona bien, sin embargo nuestro objetivo es que los desarrolladores web integren nuestra API directamente en sus aplicaciones para que ya no sean necesarios estos scripts (refiriendose a los scripts de greasemonkey) | 17:39 |
| chilicuil | nos gustaria que fuera de esta manera para que los desarrolladores originales, fueran los que modelaran su aplicacion para que brindara la mejor experiencia posible en el escritorio | 17:40 |
| chilicuil | hasta el momento aunque pocos, hemos visto que algunos desarrallores web han empezado a usar nuestra API | 17:41 |
| chilicuil | por ejemplo Rd.io | 17:41 |
| chilicuil | como se ha comentado, estas extenciones son las que manejan las modificaciones que se hacen a la aplicacion web a traves de nuestra API | 17:43 |
| chilicuil | siendo asi, existen dos extensiones, una para firefox y otra para chromium y pueden verlas en chrome://extensions | 17:43 |
| chilicuil | sin detallar mucho (aunque si asi lo requieren pueden preguntar), cada pestaña del navegador tiene un script asociada a ella, este script se comunica con otro que esta corriendo en el background de la pagina y que verifica si hay algun script de integracion disponible para el sitio | 17:44 |
| chilicuil | ese mismo script tambien ofrece sus servicios a los scripts 'normales' de las paginas para que puedan usarlo de la forma nativa | 17:46 |
| chilicuil | la logica que se esconde detras de la extension de firefox es muy parecida a la que esta en chromium, aunque en el caso de firefox se utiliza una version modificada de greasemonkey para cargar e inyectar los scripts de usuario | 17:47 |
| chilicuil | en ubuntu Quantal por ejemplo, intalamos firefox con un parche que extrae cierta caracteristica de firefox 17 que nos permite obtener el XID de una pestaña, usamos este identificador para mantener la ubicacion de la aplicacion | 17:48 |
| chilicuil | desde el punto de vista de la extension, los datos se envian a traves de la API, que a su vez envia los comandos a un servicio que esta corriendo en segundo plano en Ubuntu | 17:49 |
| chilicuil | existen dos procesos, context-daemons y webapps-service | 17:50 |
| chilicuil | webapps se encarga de las tareas comunes (que no estan relacionadas a ningun sitio en particular) | 17:51 |
| chilicuil | mientras que context-daemons hace la integracion dependiendo de cada tipo de pagina que se haya cargado | 17:51 |
| chilicuil | si escriben D-feet (el navegador de dbus) y escriben webapp | 17:52 |
| chilicuil | veran el nombre de los servicios | 17:52 |
| chilicuil | tambien podran ver algunos procesos privados, los privados representan cada uno la aplicacion web, estos se crean cada vez que se abre gmail, google docs, twitter, etc | 17:53 |
| chilicuil | bien, ahora vayamos a la parte del tutorial | 17:54 |
| chilicuil | mucha de la informacion que dejemos tambien esta accesible en webapps.ubuntu.com | 17:54 |
| chilicuil | y en http://developer.ubuntu.com/resources/app-developer-cookbook/unity/integrating-tumblr-to-your-desktop/ | 17:54 |
| chilicuil | este tutorial se centrara en el centro de administracion de tumblr, asi que si no tienen una cuenta en tumblr, pueden 1) crear una o 2) intentar probar lo que haremos con un servicio similar | 17:55 |
| chilicuil | usaremos firefox en este ejemplo, pero pueden probarlo con chromium, de hecho los invitamos a que vayan ahora mismo a tumblr.com con chromium | 17:56 |
| chilicuil | una vez ahi, presionen ctrl+shift+j para abrir la consola javascript | 17:57 |
| chilicuil | en este lugar es donde trabajaremos durante el resto del demo, el primer paso siempre sera cargar el objeto unity y siempre se hace de la misma forma | 17:58 |
| chilicuil | en su consola JS escriban "window.Unity = external.getUnityObject(1);" | 17:58 |
| chilicuil | el parametro 1 es para escoger la version de la API, asegurense que su script usa la version adecuada | 17:58 |
| chilicuil | tengan en cuenta que este script se ejecutara cada vez que abran ese sitio web | 17:59 |
| chilicuil | una de las cosas que casi siempre bera es una funcion llamada isCorrectPage() | 18:00 |
| chilicuil | esta funcion no es obligatoria, pero sugerimos que se use | 18:00 |
| chilicuil | esta funcion se asegura que el sitio web tenga todos los elementos que se esperan de el antes de comenzar | 18:00 |
| chilicuil | si nos referimos a este tutorial veremos que isCorrectPage es una funcion que llama a su vez a Unity.init | 18:01 |
| chilicuil | Unity.init es la funcion principal de nuestros scripts de usuario, inicializa el proceso context-daemon y agrega un icono al lanzador de aplicaciones | 18:02 |
| chilicuil | toma los parametros a partir de un diccionario que acepta 3 cosas | 18:02 |
| chilicuil | nombre, url_del_icono, onInit | 18:03 |
| chilicuil | el nombre es.., el nombre de la aplicacion, muy obvio, no? | 18:03 |
| chilicuil | url_del_icono es la url de donde se puede obtener el icono, puede tener la forma icon:// si se trata de un icono que esta en la maquina cliente, o la direccion web si esta disponible en Internet | 18:04 |
| chilicuil | asegurense de seleccionar un nombre que sea significativo, ese nombre se mostrara cuando se le pregunte al usuario si desea dar permisos para correr el script | 18:05 |
| chilicuil | en este ejemplo, la url del icono la hemos sacado de http://assets.tumblr.com/images/logo.png | 18:05 |
| chilicuil | entonces la linea queda como: | 18:05 |
| chilicuil | Unity.init({name: "Tumblr", iconUrl: "http://assets.tumblr.com/images/logo.png", onInit: wrapCallback(setupTumblr)}); | 18:05 |
| chilicuil | en onInit se definie el nombre de la funcion que hara el verdadero trabajo | 18:06 |
| chilicuil | una vez que el proceso se haya inializado en Ubuntu, se comunicara con el script y todo empezara a funcionar | 18:07 |
| chilicuil | como no nos queda mucho tiempo, no vemos la razon para estudiar esto a mayor profundidad | 18:07 |
| chilicuil | sin embargo nos gustaria volver a recomendar que leyeran http://developer.ubuntu.com/resources/app-developer-cookbook/unity/integrating-tumblr-to-your-desktop/ | 18:08 |
| chilicuil | y que hicieran sus preguntas en #ubuntu-webapps si les surge cualquier pregunta | 18:08 |
| chilicuil | alguna pregunta?, comentario? | 18:08 |
| chilicuil | una vez que se llame a la funcion que pongan en onInit tendran un icono que podran usar y estaran listos para usar el resto de la API para integrar la aplicacion | 18:09 |
| chilicuil | en fin, gracias a todos por asistir, espero que la sesion haya sido informativa sino que hasta inspiradora | 18:10 |
| chilicuil | ahora vayan y escriban sus propios scripts para traer al escritorio sus aplicaciones web favoritas | 18:11 |
| chilicuil | ademas de hacer sus preguntas en #ubuntu-webapps pueden hacerlas en askbuntu.com, si hacen esto, no olviden agregar la etiqueta "webapps" | 18:11 |
| chilicuil | con esto termino la interpretacion de la sesion sobre webaaps y me retiro un momento, ahora mismo se esta dando la charla sobre programacion de u1db (la api de ubuntu one) en #ubuntu-classroom | 18:12 |
| chilicuil | regresare en 1 hr para interpretar la mesa redonde que se organizara para concluir la semana del desarrollador | 18:13 |
| chilicuil | preparen todoas sus preguntas ;) | 18:13 |
| chilicuil | los logs de los 2 dias anteriores estan en: https://wiki.ubuntu.com/SemanaDesarrollador en el caso que quieran repasar algun tema, lamentablemente no hemos podido interpretar todas las charlas, pero esperamos que al menos las mas interesantes lo esten, ahi mismo estan los links para las versiones originales en Ingles | 18:14 |
| chilicuil | hola gus-tavo =) | 18:14 |
| gus-tavo | hola chilicuil, como estas ? llegue tarde a la sesion :( | 18:15 |
| gus-tavo | llegaste interpretarla toda? | 18:15 |
| chilicuil | si gus-tavo , casi me quedo atras =), te gustaria ayudar con la ultima?, Developers Roundtable ? | 18:20 |
| gus-tavo | si, voy a estar a la computadora aunque no creo que escriba tan rapido :), voy a necesitar ayuda para temninar ! | 18:22 |
| chilicuil | seguro, cuando te canses me avisas y te ayudo a terminar | 18:31 |
| gus-tavo | gracias ! pero te aviso por este mismo canal, despues podes borrar esas entradas en el log? | 18:36 |
| chilicuil | si se ponen en un pastebin (menos profesional) si, si apunto a irclogs.ubuntu.com no | 18:39 |
| gus-tavo | bueno, enseguida entonces comienzo, y cuando me quede atras te aviso, gracas | 18:40 |
| chilicuil | gus-tavo: nop | 18:42 |
| chilicuil | gus-tavo: todavia no, me referia a la sesion que comenzara dentro de 20 min | 18:42 |
| gus-tavo | si, si, te entendi, faltan 15 min aproximadamente | 18:43 |
| chilicuil | ahh, ok =) | 18:43 |
| gus-tavo | En esta sesion basicamente queremos interactuar con los desarrolladores, si eres un dessarrollador, saludos, y que comiencen las preguntas ! | 19:03 |
| gus-tavo | pueden compartir sus experiencias como desarrolladores mas tarde, | 19:04 |
| gus-tavo | alguna pregunta? | 19:04 |
| gus-tavo | wan26 pregunta: Quiero comenzar a desarrollar pero no se como empezar | 19:07 |
| gus-tavo | wan26: seguro que mucha gente tiene el mismo problema o/ | 19:08 |
| gus-tavo | alguien mas ? | 19:08 |
| gus-tavo | bdrung dice: comencé como desarrollador Ubunto haciendo mis investigaciones. necesitaba una nueva version de matplotlib y trate de actualizar el paquete | 19:10 |
| gus-tavo | bdrung, podrias contarnos mas de tu experiencia? La tuya es como la mía, haciendo mis propias investigaciones | 19:11 |
| gus-tavo | bdrung: esa es una buena motivacion para comenzar a trabajar en software libre | 19:12 |
| gus-tavo | encontrar algo es facil: probablemente has experimentado un error que te hace querer una nueva version de un programa, pero no esta actualizado | 19:15 |
| gus-tavo | hace 4 años, participe en una fiesta de empaquetado en la que dholbach explico como se hacia el empaquetamiento | 19:16 |
| gus-tavo | vi todas las herramientas en un corto periodo de tiempo y fui capaz de usarlas | 19:17 |
| gus-tavo | el empaquetado son varias herramientas de la linea de comandos y formatos de archivos | 19:17 |
| gus-tavo | ScottK: encontrar el error es un comienzo, pero no es lo que me sostiene. Pienso que la gente deberia hacer un poco para que el mundo sea un mejor lugar y contribuier al software libre es parte de lo que hago por eso. un par de años atras escribi: | 19:19 |
| gus-tavo | https://skitterman.wordpress.com/2009/05/31/back_home_from_uds_karmic/ | 19:20 |
| gus-tavo | bien, alguien mas quiere compartir sus experiencias? | 19:20 |
| gus-tavo | chilicuil pregunta: tengo una pregunta, si no molesta mientras están hablando de sus experiencias. cuáles son sus herramientas favoritas/más usadas en el paquete ubuntu-dev-tools? | 19:21 |
| gus-tavo | hay un montón: syncpackage, wrap-and-sort, sponsor-patch me vienen a la mente | 19:22 |
| gus-tavo | syncpackage es para sincronizar un paquete desde Debian a Ubuntu. si no tienes derechos para subir, probablemente uses requestsync | 19:23 |
| gus-tavo | wrap-and-sort hara que tu archivo debian/control se vea bien (al menos para mi) | 19:24 |
| gus-tavo | cdunlap pregunta: donde encontrar alguna de estas fiestas de empaquetado? | 19:25 |
| gus-tavo | los desarrolladores usan las herramientas de una forma muy distinta, y eso esta bien | 19:26 |
| gus-tavo | yo uso syncpackage todo el tiempo, pero nunca uso las otras dos | 19:26 |
| gus-tavo | sponsor-patch es para esponsorear un paquete para alguien mas, este descarga el paquete fuente, le aplica los parches propuestos, prueba el resultado. esta herramienta me permite concerntrarme en mirar solo los cambios propuestos | 19:29 |
| gus-tavo | pienso que todavia se estan haciendo las fiestas de empaquetado, pero no hay necesidad de esperar. yo aprendi antes de que existieran. si tienes algo en que trabajar, solo zambullete y comienza, la gente en #ubuntu-motu estara contenta de ayudarte si tenes tropezon | 19:31 |
| gus-tavo | deberias intentar con wrap-and-sort! :) | 19:32 |
| gus-tavo | hay mucha documentacion (mas que abrumadora!), pero asi como estes tratando como y no esperar a las soluciones, hay gente que te ayudara | 19:34 |
| gus-tavo | no te preocupes por no aparecer como que no sabes del tema cuando preguntes. He estado haciendo esto desde el 2007 y todavia tengo preguntas | 19:35 |
| gus-tavo | no puedo recordar cuendo tuvimos la ultima fiesta de empaquetado. La Semana de Desarrollador Ubuntu es un evento equivalente que puede dispararnos hacia el desarrollo | 19:36 |
| gus-tavo | me he dado cuenta de que la gente escribe diferentemente codigo , como tratar con eso si tengo otro estilo, o hay algun estilo general al que adherir? | 19:38 |
| gus-tavo | el mayor problema que veo es gente que comienza a desarrollar es que no comienza por sí sola. este no es un trabajo regular con un jefe frente a ti diciendo que es lo que se necesita hacer hoy. Tenes que encontrar la motivacion a tener algo hecho. si lo encuenteas, es probable que lo termines, porque el conocimiento tecnico para la mayoria de las actividades de empaquetado no son complejas | 19:42 |
| gus-tavo | (hay mucho de esto, pero las piezas individuales no son duras) | 19:43 |
| gus-tavo | calmi pregunta: para los desarrolladores con experiencia: pueden abstraer su punto de vista ? ej, pueden ponerse en la posicion de - diremos a tu padre con pocos conocimientos de computadoras, como hacer las cosas? | 19:45 |
| gus-tavo | wan26: la distribucion de paquetes e primariamente un trabajo de integracion, no tenemos que escribir mucho codigo desde cero. si estas trabajando en un parche para solucionar un error, o mejor en Ubuntu, generalmente queres adherir al estilo del upstream, por la consistencia y maximizar las chances de que el parche sea aceptado | 19:48 |
| gus-tavo | es dificultoso. a menudo le pregunto a la gente que es nueva en el desarrollo que arreglen la documentacion antes de hacerlo yo, ellos estan mejor posicionados para escribir que funciona para la audiencia de nuevos desarrolladores que yo | 19:51 |
| gus-tavo | chilicuil pregunta: usan un sistema de desarrollo distribuido (ramas/fusiones) o adhieren al estilo debian de produccion de parches? piensan que la forma de Ubuntu esta lista para ser usada de forma segura para los nuevos contribuidores? cuales son algunas de las cosas alli que Ubunto no puede manejar? | 19:55 |
| gus-tavo | nunca uso UDD | 19:55 |
| gus-tavo | trate, pero lo encontre complejo y las herramientas no estan maduras | 19:56 |
| gus-tavo | creo que es un error enseñarle a la gente desde que entran a la rama que está desactualizada, tiene que hacerlo a la vieja escuela, tambien necesitan ese conocimiento | 19:57 |
| gus-tavo | calmi: buena pregunta. Ayudo a mucha gente en mi vecindario a mantener Ubuntu. viendo como interactuan con una computadora veo las diferencias en el uso. trabajo rapido y casi siempre en la lines de comandos, pero eso no explica de que otros hagan lo mismo | 19:59 |
| gus-tavo | si queres envolverte con Debian (que lo recomiendo), estas en el mejor de los conocimientos con mas herramientas en general | 20:00 |
| gus-tavo | dicho esto, me encantan las ramas de empaquetado que son generadas con cada subida. hace muy facil ir atras y figurar que es lo que ha cambiado, cuando y porque | 20:02 |
| gus-tavo | es una herramienta sorprendente de análisi | 20:02 |
| gus-tavo | alguna pregunta o ideas? | 20:02 |
| gus-tavo | bdrung: raramente uso UDD. hago la mayoria de mi trabajo con algunas herramientas de control de version Debian (en la mayoria de los casos: git) | 20:04 |
| gus-tavo | eso nos trae otro buen punto. los dos, bdrung y yo somos desarrolladores Debian | 20:04 |
| gus-tavo | comenzamos con Ubuntu y migramos para comenzar a trabajar en Debian tambien | 20:05 |
| gus-tavo | muchos desarrolladores Ubuntu son tambien desarrolladores Debian (tanto como conozco) Que los hace a Uds. tambien comenzar a participar en Ubuntu? | 20:06 |
| gus-tavo | para los paquetes que mantengo, en la mayoria de los casos los subo a Debian y sincronizo | 20:07 |
| gus-tavo | comence en Ubuntu | 20:07 |
| gus-tavo | Mas gente se beneficia si haces las cosas en upstream | 20:07 |
| gus-tavo | exactamente | 20:07 |
| gus-tavo | jincreator: comencé en Ubuntu y luego Desarrollador Debian (DD) | 20:08 |
| gus-tavo | tambien si algun cambio es hecho en Ubuntu, lo porto a Debian, eso es menos trabajo para Desarrolladore Ubuntu | 20:10 |
| gus-tavo | Es importante. Debian tiene en orden de magnitud mas desarrolladores que Ubuntu, es critico para mucho que las cosas se hagan alli | 20:11 |
| gus-tavo | haciendo cosas en Ubuntu te dara una diferencia (diff) entre Debian y Ubuntu. Asi un Desarrollador Ubuntu necesita mantener esta diff. toma tiempo que puede ser usado para algo más | 20:13 |
| gus-tavo | Tambien los mantenedores de paquetes Debian son expertos en sus paquetes, asi trabajar con gente Debian te dara una buena retroalimentacion que es dificil de obtener en Ubuntu, donde la mayoria de los desarrolladores son generalistas y pocos paquetes tienen dedicados un mantenedor | 20:16 |
| gus-tavo | Debian tiene cerca 1000 desarrolladores. Ubuntu alrededor de 150 | 20:16 |
| gus-tavo | Conozco a desarrolladores Debian que se han integrado en Ubuntu | 20:17 |
| gus-tavo | ne orden de dificultad, como clasificaria las tareas que hacen? | 20:18 |
| gus-tavo | generalmente, parece ser el deseo de aprender acerca de problemas con paquetes (Ubuntu tiene muchos usuarios y archivos con muchos errores) o considerar preocupante acerca de los usos de los derivados de Debian como Ubuntu, extensión natural del Contrato Social de Debian. | 20:22 |
| gus-tavo | eso depende. haciendo una tarea especifica la primera vez puede ser dificil. haciendola la decima vez es facil | 20:23 |
| gus-tavo | digamos, que comienzas contribuyendo arreglando algun error, escribiendo algun parche, que es los siguiente? como vas del digamos contribuidor casual a desarrollador Ubuntu? | 20:25 |
| gus-tavo | quiero decir, men encontre creando un parche para un paquete ubuntu mucho mas facil (si no es uno dificil) que fusionando o trabajando con FTFBS, nunca logre arreglar algunos de esos | 20:28 |
| gus-tavo | stadtfeld: usualmente la gente es considerada seriamente como ubuntu dev si han contribuido al menos seis meses | 20:29 |
| gus-tavo | chilicuil, me tengo que ir ! | 20:32 |
| chilicuil | gus-tavo: ok, gracias o/ | 20:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
