 Bueno, pues continuamos con la plática de Mónica Ramírez Arceda, Debian QA, una puerta de entrada al proyecto de Debian. Y aprovecho también para invitarles hoy a las 8 de la noche al concierto Bailongo mueve el mouse con libertad en la escuela de danza frente a la universidad y tendrá un costo de 30 pesos la entrada y ahí los esperamos para que pasemos un buen rato de baile y de mouse. Vale Fernanda, digo Mónica. Bueno, pues me presento, soy Mónica Ramírez Arceda y soy profesora de informática y empecé con el tema de software libre ahora ya más de 10 años empecé en un hack lab en Barcelona, sobre todo difundiendo su uso haciendo cursos, etcétera y ahora unos dos años quise pasarme a la parte un poquito más técnica me apetecía más y empecé a colaborar con Debian directamente para devolver a la comunidad todo lo que me había dado. Entonces mi charla era de una posible manera de entrar en Debian, sobre todo para todos para todos aquellos que no tenéis un interés especial en una cosa concreta sino de quiero ayudar en Debian y no sé por dónde empezar pues yo creo que esta es una buena puerta de entrada para cualquiera que quiera hacer algo un poquito técnico pero no tenga las ideas muy claras. Primero lo que me gustaría hacer es dar una visión general de la complejidad que tiene el proyecto de Debian. Lo que es la distribución como ya se ha comentado en algunas charlas anteriores se basa en paquetes, es decir lo que nos instalamos nosotros en el ordenador son paquetes pero los paquetes no solo son de programas por ejemplo aquí puesto que hay paquetes de programas como puede ser el GIMP, Ice Whistle, etcétera pero tenemos muchas cosas más por ejemplo librerías es decir los programas informáticos normalmente usan librerías que también están en sus paquetes respectivos. Tenemos más tipos de paquetes por ejemplo paquetes con documentación que ya no son ni programas que van solos sino que es documentación que nos podemos instalar en nuestro ordenador, incluso más tenemos paquetes diferentes como por ejemplo los paquetes virtuales que simplemente es un paquete que nos da opciones de instalar por ejemplo el WWW browser nos deja instalar diferentes navegadores o metapaquetes que no tienen contenido dentro sino que son dependencias de otros paquetes con software, librerías, etcétera. Hablaba de esto también, los paquetes no son individuales sino que dependen los unos de los otros y a veces incluso la dependencia se basa en sus versiones y eso nos lleva a transiciones es decir cuando yo estoy utilizando un paquete y ese paquete cambia algunos otros paquetes necesitan saber de ese cambio y eso nos provoca que se tenga que coordinar una transición. Una vez hablado del software me gustaría también poneros en cuestión todo el tipo de personas que van a que están haciendo de alguna manera que debían exista. El primero tipo de personas serían los autores de software es decir lo que nosotros llamamos muchas veces upstream es decir las personas que desarrollan que programan los programas que nosotros al final convertiremos en paquetes y nos podremos instalar en el ordenador. Todo este conjunto de gente no tiene porque ser directamente colaborador de debían aunque algunos sí que lo son pero sí que desde debían nos tenemos que coordinar con ellos pues yo que sé para saber cuando vamos a pasar de versión si prevémos que habrá una versión estable de debían decir a ver si podemos coordinarnos un poquito etcétera. Después tenemos también colaboradores puntuales, es decir no gente que está comprometida con debían pero que a lo mejor detecta un error y nos reporta un bug o nos arregla ese error dándonos un patch etcétera. Pero son colaboradores puntuales que cada uno pues son también las cosas de su manera etcétera. Tenemos también colaboraciones que nos llegan desde otras distribuciones derivadas quizás la más famosa es Ubuntu, desde allí también hay gente que está arreglando errores que podemos nosotros recopilar desde debían y poderlos incorporar en nuestra distribución. Quiero que vayáis pensando la cantidad de gente que está involucrada en todo esto porque a veces se habla de mil desorraldadores de debían pero aquí estamos hablando de un montón de gente más. ¿Qué más tenemos? Tenemos gente que son mantenedores esponsorizados. ¿Qué quiere decir eso? Gente que no tiene permisos en el repositorio de debían pero que hace su aportación y consigue que otra persona que sí que tenga permisos les suba su paquete. Que es lo que normalmente pasa cuando empiezas a colaborar con debían y empiezas a empaquetar. Es decir lo que haces normalmente es haces tu arreglo, lo pones en algún repositorio que se pueda acceder y alguien que le interese que esté en debían te lo sube. Estos serían mantenedores esponsorizados. También hay los debían mantenedores. Debían mantenedores es gente que tiene permisos en el repositorio pero sólo para los paquetes que él mantiene. La gente que ha hecho que es debían mantenedor muchas veces ha pasado antes por ser un mantenedor esponsorizado y que al final pues ha pedido que pueda él subir directamente al repositorio los paquetes que él ha creado. También tenemos los debían developers que es la gente que tiene permisos que ya tienen un compromiso más directo con debían y que puede subir sus paquetes y también tocar él de los otros. O sea puede intentar arreglar, tiene permisos para arreglar paquetes del resto de mantenedores. A lo mejor me estoy saltando alguna cosa lo que sí que quiero que dé claro es que los paquetes en general se responsabiliza una persona. Cada uno de los paquetes que tiene debían una persona o más se responsabilizan de él. Toda esta gente que hemos dicho antes pueden organizarse también a su vez en equipos que lo que se llaman debían teams. Con la cual cosa tiene cada equipo tiene una manera de trabajar diferente y puede ser debían developers, con debían mantener con colaboradores etcétera. Para poder trabajar de una manera más o menos homogénea hay varios documentos que nos ayudan a hacer las cosas un poquito más homogéneamente. Por ejemplo tenemos el debían social contract que incluye las directrices de debían, creo que se ha hablado en anterior charlas. Hay el developer reference que nos sirve también para poner un poco de guías de cómo hacer las cosas y sobre todo muy importante la debían policy que establece unas directrices de cómo tienen que estar técnicamente los paquetes que nosotros empaquetamos. Bueno pues todo esto y estoy simplificando muchísimo podríamos decir que es debían. ¿Dónde entra? ¿Dónde entra debían kuá? Debían kuá es el equipo que procura por la calidad de debían. Entonces podríamos decir que intenta, igual que estos son como pequeños grupos de gente que va intentando hacer las cosas lo mejor posible, hay un equipo que lo que intenta hacer es ver debían como un todo, o sea ver tanto el software como la gente que está colaborando, intentar poner herramientas para que toda esta complejidad que he intentado explicaros sea lo más homogénea y lo más calidad posible. La prueba es que debían tiene una fama de tener una calidad bastante alta por lo tanto esto funciona, increíblemente funciona. Voy a dar ahora un poquito una introducción de algunos de los ejemplos de debían kuá, algunas de las herramientas que genera y algunos de los subproyectos que tiene. Bueno el primero serían estas dos herramientas no sé si las conoceis, os voy a hacer una breve introducción que son el DDPO y el PTS. El DDPO lo que nos da es una visión de cada uno de los desarrolladores, mantenedores de debían. Podremos ver qué paquetes mantiene y otras cosas que ahora os iré explicando un poquito más lentamente. Entonces os voy a abrir el DDPO de uno concreto, bueno es el mío. ¿Qué es lo que vemos aquí? Bueno estas herramientas que os voy a enseñar lo que demuestran también es la completa transparencia de debían, o sea podéis ver en cada momento cómo está cada paquete que hace cada persona, etcétera, etcétera. Por ejemplo aquí lo que se puede ver es de un desarrollador concreto qué paquetes está utilizando, qué errores tiene cada uno de los paquetes, qué versiones hay en cada uno de los paquetes con lo cual cosa podremos ver también si otro desarrollador ha subido versiones del paquete que estamos manteniendo. También vemos la versión de Ubuntu, podemos acceder a los logs de la compilación del paquete que estamos manteniendo, etcétera. Aquí por ejemplo podemos ver también si hay problemas con las dependencias que comentaba antes. Popcon es el uso del paquete, cuánta gente está usándolo, de los que hayan aceptado colaborar en esta encuesta y finalmente también saber si ha salido una versión nueva del programa original. Además aparte de poder ver aquí en esta herramienta que podemos ver los paquetes mantenidos tenemos más información. Por ejemplo hablaré un poquito más tarde de qué quiere decir estas siglas. Aquí básicamente muchas veces nos sale paquetes que yo ya no quiero mantener o paquetes que tengo intencionalidad de mantener más adelante. También podemos ver si el mantenedor es un desarrollador de Debian, podemos ver las subidas de paquetes que no son nuestros. Por ejemplo este de aquí no es un paquete que sea mío pero yo había un pequeño bug y lo arreglé. Entonces lo subí y quedó como un non Bueno hay varios aquí. También tenemos los QA uploads que son paquetes que no quieren nadie y los tiene que mantener el equipo de CUA. El equipo de calidad mantiene una serie de paquetes que no quieren nadie y de vez en cuando pues si tienes ganas actualizas la versión, arreglas bugs, etcétera. Y además como os comentaba antes tenemos bueno las personas que son desarrolladoras de Debian pueden sponsorizar subidas a gente que no tiene permisos o sea que con esta página del DDPO podemos ver cada uno de nosotros cada uno de las personas que están colaborando en Debian sean desarrolladores o sean simples colaboradores que es lo que están haciendo y cómo están los paquetes que están manteniendo en cada momento. También tenemos esta otra que es el PTS Package Track System que lo que nos dice es de cada paquete toda la información salía ya en la otra herramienta pero aquí está como mucho más detallada. Podemos ver quién la mantiene, si está mantenida en un repositorio de versiones, qué versiones hay actualmente, las últimas noticias cuando se han subido los paquetes, etcétera. También tenemos aquí un conjunto de enlaces interesantes de cada uno de los paquetes o sea si sois curiosos os lo podéis pasar pipa porque es puedes curiosar cualquier cosa incluso si te da pereza ir mirando cada uno de estos paquetes cada día te puedes suscribir a cada uno de los paquetes para recibir todas las noticias que vayan apareciendo, recibirlas por correo electrónico. Estas herramientas que os estoy enseñando, repito, las mantiene el equipo de Debian QA, el equipo de calidad. Muy bien, ¿qué más tenemos? Existen dos programas también mantenidos desde el equipo de calidad que son Lintian y Pewparts. Lintian es un programa que nos sirve para chequear, para comprobar que nuestros paquetes han estado, no nos hemos descuidado ninguna cosa de las que establece las políticas de Debian o sea que cuando tú en paquete es un paquete pues te puedes equivocar y como que te puedes equivocar pues ejecutas un programa que comprueba que todo esté en orden y si tú no lo ejecutas en cuanto lo subas habrá una aplicación web que es la que estamos viendo aquí que lo pondrá visible de que por ejemplo Mónica tiene un programa que se llame así que no tiene página web, no le he puesto la página web básicamente no la puse porque no tiene, pero me lo recuerda hay diferentes grados de importancia de cada uno de estos errores, por ejemplo la P quiere decir de pedantic que es como un poco tiquismiquis y de todos los paquetes de Debian podemos ver cuáles son aunque funcionen que funciona no quiere decir que esté bien hecho aunque funcionen pues podemos ver cuáles son los pequeños errores que tendríamos que pulir para que fuera perfecto. Además también tenemos, esto como he comentado es un programa que podemos ejecutar sobre nuestros paquetes empaquetados y además un servicio web que nos ofrece los resultados de los programas subidos a Debian. También tenemos Pewparts, Pewparts es un programa que lo que te haces instalar, desinstalar, actualizar el paquete para ver que no haya ningún problema cuando este paquete esté subido. También es un programa que podemos ejecutar en nuestra máquina o ir a un servicio web que nos dice si ese paquete está bien o no está bien, o sea se ha superado todas las pruebas que tiene Pewparts. Finalmente bueno finalmente no me quedan varias cosas pero una de las cosas que antes ha salido que salía en el DDPO era los paquetes WNPP WNPP es Work Needing and Package Prospection o algo así creo que lo que quiere decir básicamente es paquetes que necesitan trabajo, que se tiene que trabajar en ellos. Esto se hace básicamente reportando un book contra un paquete que no existe que se llama WNPP y lo que puedes y haciendo esto lo que conseguimos es tener tres tipos de errores que no son tales pero que nos puede ayudar para saber dónde podemos ayudar por ejemplo RFP es que alguien dice yo utilizo un programa y no están debian pues reporto un book a debian diciendo me gustaría que alguien en genérico me empaquetara este paquete para mí para poderlo tener en mi distribución favorita que evidentemente es debian. Tenemos también el request for help que son desarrolladores o mantenedores que están trabajando en paquetes pero quieren ayuda necesitan ayuda o porque no saben cómo solucionar algún problema o porque les supera las horas de trabajo que tienen que dedicar. Finalmente estos dos es cuando un mantenedor por el motivo que sea quiere dejar de usar de mantener ese paquete dice ya no lo uso no me apetece ya estoy desmotivado con este paquete voy a dejarlo huérfano el primer paso normalmente es que haga un request for adoption es decir comunidad de debian mantenedores quien sea por favor ayudarme y adoptar este paquete que yo ya no lo quiero directamente o pasando por este paso a veces lo que se hace es orfanearlo directamente o sea se dice yo ya no quiero mantener esta paquete lo dejo huérfano cuando se deja huérfano pasa a ser de debian qa pasa ser del equipo de calidad de debian podemos dar un vistazo a todos los paquetes que cumplen que están en estas veis aquí tenéis toda una serie de paquetes por ejemplo los rfp son paquetes que no están en debian que no existen y que hay gente que ha pedido a debian a la comunidad que los incluyen la distribución todos los que tienen una o son paquetes huérfanos que nos está haciendo cargo nadie pero que aún están en los repositorios y por lo tanto como equipo de calidad se quiere que sean lo más perfectos posibles que no tengan bugs que lo que sea entonces la única solución es o mantenerlos entre todos o si se da el caso porque no son suficiente importantes incluso borrarlos me gustaría hablar también de este subproyecto de debian que es el equipo mía que es missing in action y la primera vez que lo oí me di una sensación de es gente que no hace nada y que los tenemos que echar no y te sentía te sientes como mal como un chivato no de este no está ocurrando y luego ves que no es así es un poquito lo que dice este dibujo no despierta te necesitamos en debian es decir gente que a lo mejor ha dejado por el motivo que sea ha dejado a colaborar y a lo mejor con un simple mail revive y vuelve a ayudar y esa es la intención principal del equipo de mía que es intentar recuperar colaboradores antiguos o si es el caso si la persona dice no no es que ya no quiero colaborar pues decir bueno pues orfaneamos tus paquetes y que los los mantenga otra persona bueno podría extenderme de hecho cada transparencia quedado podríamos estar hablando durante toda una charla de ellas y aún hay muchas más herramientas que se están manteniendo desde desde debian cual por ejemplo una de las cosas que se hace es envío masivo de debax se coge una de las tareas que se hace es se coge todo el archivo de debian y se vuelve a compilar todo y hay paquetes que dejan de compilar por qué pues porque a lo mejor ha habido una librería que ha cambiado y un paquete ya no funciona etcétera etcétera entonces una vez se detecta este problema se envían bugs a todos estos a todos estos paquetes también hay el proyecto de ultimate debian database que lo que haces recopilar es una base de datos que recopila toda la información bueno mucha información de debian es decir los paquetes los errores de los paquetes mantenedores que están utilizando estos paquetes etcétera de cheque lo hemos visto en el pp en el dp o lo que nos haces mirar es que no haya problemas con las dependencias patch tracking hace un seguimiento de los cambios que hace debian respecto a los programas originales el debian developer portfolio service esto si sois chafarderos ya es el sumum porque puedes ver de cada programador absolutamente todo lo que hace es completamente una transparencia total esta herramienta de aquí nos sirve para ver la diferencia de versión que hay en debian comparado con con el programa original podríamos estar ya digo hablar hablando de cada una de estas herramientas podría estar toda toda la tarde casi bueno pues ahora vamos a la pregunta que es cómo colaboró se ha dado una visión general muy simplificada es mucho más de lo que he explicado y me gustaría saber de los que estáis en la sala quién se considera una persona curiosa me levanta en la mano vamos bien y de los que están en la sala quién sabe enviar un correo electrónico quien no levanta la mano no le voy a creer también podríamos preguntar quién sabe programar quien tiene unas nociones mínimas de programación aquí a lo mejor ya no todo el mundo pero alguien sí y quién tiene alguna noción de empaquetar un paquete debian que si no sabéis no pasa nada porque hay documentación extensísima para hacerlo en alguna de estas cuatro preguntas habéis levantado la mano se ha quedado y trabajo para todos nos preocupéis vamos a ver qué podemos hacer yo creo que la manera más fácil para empezar a colaborar es solucionando errores solucionando bugs os he puesto cuatro opciones la primera sería esta que es utiliza es intentar solucionar a bugs críticos que se llaman rc bugs release critical box que son estos que son estos bugs son bugs tan graves que podrían retrasar la nueva versión de debian con la cual cosa si algún día decís ahí estoy aburrido y no decidís ir a la playa podéis solucionar un bug rc que son los que realmente interesan que se solucionen lo más rápido posible ahí tenemos bastantes actualmente aquí tenéis una gráfica de todos los bugs bueno veis que aquí hay caídas ahora se acaba de congelar la la la distribución de test de testeo de debian y por lo tanto tenemos que intentar que estos bugs caigan en picado o si puede ser a cero si tenéis ganas y sabéis programar un poquito pues y sabéis un poquito de manejo de de empecatamiento es una buena manera de empezar os he puesto esto de aquí es una iniciativa que creo que empezó este fanos a quiroly que es vamos a hacer unos cuantos bugs a la semana no vamos a solucionarlos cuando eres desarrollador de debian puedes solucionarlo y subirlo al archivo pero si no eres desarrollador de debian también puedes hacerlo simplemente lo enviarás al gestor de errores de debian y allí alguien en principio si está bien hecho lo subirá por ti o sea que no tienes por qué ser para solucionar un bug de estos no tienes porque tener permisos puedes empezar a hacerlo lo envías y algo lo hará por ti yo hago a veces broma que en lugar de rcb v doble puede ser rcb m a unos al mes no hace falta que sea la semana pero mientras hagas alguno pues ya está bien no a otro tipo de bugs son los bugs de los paquetes huérfanos tenemos un montón de paquetes huérfanos y al tener tantos vamos a los voy a enseñar veis todo actualmente hay 476 paquetes que están en el aire en el aire no los tiene que mantener el equipo de debian entonces todos los bugs que aparecen aquí alguien los tiene que arreglar y no hay una persona que se haya responsabilizado de ellos por lo tanto si uno de estos paquetes os interesa y veis que tiene un error no esperéis a que lo solucionen por vosotros si podéis hacerlo y sabéis hacerlo pues sería una manera bonita también de colaborar también tener en cuenta que hay algunos paquetes que a lo mejor a la larga desaparecerán porque son paquetes muy poco usados o están obsoletos etcétera o sea que es mejor que intentéis hacerlo con paquetes que vosotros os gustan también podéis solucionar errores de la infraestructura de de biancue y todas las herramientas que os he dicho antes el pts de dpo etcétera tienen también errores y por lo tanto la gente los reporta y se tienen que solucionar creo que también tengo el el link aquí tarda un poquito más aquí veremos una serie de bueno veis tenemos un montón hay una serie de de errores relacionados con las herramientas que os he dicho antes el pts de dpo de check entonces si alguien tiene ganas de solucionarlas pues también tenéis aquí un montón de errores posibles a solucionar y finalmente reportando errores supongo que en otras charlas y os lo han dicho que una manera muy eficiente también es reportar aunque aunque tú no sepas a solucionarlos si tú detectas un error lo tienes que notificar sobre todo si es muy grave otra manera de reportar de reportar errores es perdón otra manera de de utilizar el el pts es ayudando porque a veces hay hay incongruencias si aprendéis a cómo funciona el sistema de errores de debian hay hay a veces que hay alguna inconsistencia que también puedes arreglar sin tener ningún tipo de permiso muy bien todo esto de momento os está dando bastante trabajo no vamos a ver más si por ejemplo uno de los paquetes que he dicho antes os he dicho podéis coger paquetes que están huérfanos que están manteniendo el equipo de calidad y podéis arreglarles books en en en genérico pero podéis hacer incluso más si os gusta ese paquete o sabéis empaquetar y tenéis ganas de colaborar lo mejores a adoptarlo porque sino también pensar que si se queda en el en el en el agujero del equipo de calidad podría llegar a desaparecer de hecho mi primer paquete fue así cogí y adopte uno porque hay tantos que ya los que me interesaban a mí ya los estaba manteniendo alguien pues cogí uno pequeñito que te sientas un poco cómodo al principio lo adoptas y empiezas a trabajar con paquetes otra cosa que se puede hacer si no quieres adoptarlo pero quieres que ese paquete crees que es necesario para debian hacer una subida de cua que es una subida de cua pues tú actualizas ese paquete y dices no me voy a mantenerlo pero que que haya una nueva versión de acuerdo eso sería un cua upload también tenemos toda la infraestructura si sabéis programar podéis colaborar en la programación de la infraestructura os he puesto antes unos cuantos ejemplos el dp o etcétera hay un montón incluso se pueden crear nuevos proyectos como me comentaron en la lista el otro día uno que se llama clonquais que es que lo que mira es que los paquetes no tengan librerías envedidas no las tengan dentro sino que ya sean otros paquetes hay un montón de programas que ya existen o incluso que nos podemos inventar que lo que hacen es un chequeo de todo lo que estamos haciendo finalmente los que me habéis dicho somos curiosos y sabemos enviar mails esta es una tarea muy fácil cuando veáis que tenéis algún paquete que veáis que no sé que tiene muchos errores que nos está actualizando veis que por ejemplo que tiene muchos en emeo es decir que otra gente les está intentando ayudar sacando nuevas versiones lo veréis porque estará en rojo que tiene un montón de bugs que la última actualización se hizo por ejemplo en este caso el 2008 pues podéis enviar un correo a esta gente decir me parece que este mantenedor ahora mismo no está activo a ver si vosotros podéis animarle a que vuelva de bien y finalmente es hecho esta tabla que lo que pretende hacer es de alguna de las tareas que os he dicho como arreglar rc bugs arreglar bugs de nvp etcétera cuando está en verde serían cosas que tendríais que saber un poquito hay documentación por un tubo o sea que podéis consultarlo y en algunos casos cuando he puesto esto naranja quiere decir que depende del caso por ejemplo para enviar bugs masivos pues depende del caso se tiene que saber un poquito de empequetamiento o no de acuerdo pero yo creo que detectar posibles mía sería una cosa que podría hacer casi cualquier persona bueno espero haberos animado a colaborar con este equipo y antes de acabar si tenéis alguna pregunta no si este bueno yo he tenido la curiosidad de verdad de saber cómo puedo empezar a colaborar con el proyecto debia alguna vez me metí a leer los manuales por donde empezar pero de repente yo siento que es demasiado es decir el la culpa de aprendizaje es bien empinada por decir lo de alguna forma entonces durante un tiempo también estuve intentando apoyar con la con las traducciones pero por ahí escuché en algún correo leí o escuché no recuerdo de que lo que realmente hacía falta en el proyecto debia era más gente que apoyara con el desarrollo y con el mantenimiento de paquetes y bueno y quiero hacer un paréntesis verdad en ese punto porque por ejemplo aquí en micaragua nosotros tenemos una comunidad bien activa pero es más que todo activista la comunidad entonces vemos que nuestra comunidad yo siento que la comunidad de software libre tiene que ser como una pirámide no pero nosotros lo que tenemos aquí es una pirámide invertida de decir la parte donde debería estar la mayor cantidad de personas que colaboran está invertida de decir son poquitos y los activistas que deberían ser pocos van los evangelizadores somos muchos decir bueno no está mal entonces yo vemos que para mí esto es una buena forma de empezar pero me gustaría escuchar por ejemplo que vemos cuáles son si tuviéramos que tenemos 10 personas o 15 personas que quieren colaborar y hay que motivarlo de alguna forma para que ayuden a mantener paquetes qué tanto peso tiene el tema de las traducciones de la localización en relación al mantenimiento de paquetes no sé por ahí quiero no sé si te sabré contestar a lo mejor me podría dar una mano porque yo creo que se necesita trabajo en todos los en todos los ámbitos te puede decir antes has visto hay como 400 paquetes unos mil rc bugs o sea yo creo que tienes que haber un problema que te puedes encontrar en debian y lo digo por experiencia propia es que nadie te va a decir qué tienes que hacer y eso eso en teoría es bueno porque te da libertad pero hay un momento que lo que dices tú la curva de aprendizaje no es tanto la curva de aprendizaje sino que te sientes perdido no como un vacío de que hago por dónde empiezo y tienes que empezar a hacer algo lo que sea lo que te sientas tú más cómodo probarlo y perder vergüenza sobre todo y lanzarte no yo no no o sea decir dónde hace falta más más peso yo creo que no no es lo o sea tienes que hacer algo que te motive porque si no luego también te vas a dar por ejemplo yo adopte algún paquete que ahora me me arrepentía en plan de bueno pues si no lo coge nadie hay gente voy a hacerlo yo pero luego al final también te hartas no porque si no lo usa si no te motiva mejor no hacerlo o sea que mi consejo sería si tenéis ganes de colaborar no os preguntéis tanto dónde se necesite más ayuda sino con lo que te diviertes más si te diviertes traduciendo traduce si te diviertes empaquetando yo me lo paso pipa y habrá gente que dirá que eso es un rollazo no lo que te petezca más y lo bueno de los lo que comentaba los paquetes huérfanos que a veces hay críticas que dicen no es que los paquetes huérfanos es lo que no lo que nadie quiere no sé que no sé pero yo me sentí mucho más cómoda porque bueno era algo son unos paquetes que necesitan ayuda porque no los está manteniendo nadie hay algunos muy pequeñitos muy fáciles de mantener y y creo que es un buen sitio por donde comenzar si ya sabes un programa que te interesa que lo quieres que lo quieres empaquetar también está bien no pero si no sabes por dónde coger uno pequeñito de que esté huérfano intentar le dar un un un limpiado de cara no sé yo es como lo hice pero no es una solución perfecta cada uno tiene que encontrar la suya y es difícil quisiera agregar mi mi punto de vista un poco a lo que pregunta denís este yo no veo mucho la diferencia si tú encuentras un fallo en una traducción bueno para meterla vas a tener que aprender un poquito de cómo se hace el paquete todas las tareas están de algún modo relacionados son diferentes pero son lo mismo entonces también haciendo traducciones estás haciendo mantenimiento especialmente cuando empiezas a ver qué las traducciones se lo que le llaman se pudren o se oxidan si cuando una traducción se empieza a oxidar pues el programa que llama esa traducción va a empezar a desplegar un comportamiento incorrecto y pues bueno ahí es donde tú entras como como auxiliar de traducción pero tienes que mantener el paquete como sea más que quiera hacer alguna pregunta bueno en general no relacionado directamente a la charla pero si me gustaría que comenzaron un poco sobre debian women pero que habemos pocas mujeres acá pero es muy importante como podemos colaborar también incluso que hablar a un poco de debian web es que estoy un poquito sorda si me gustaría saber un poco más sobre debian women si también puedes comentarnos un poco sobre eso ya que a pesar de que vemos pocas mujeres a ver muchas interesadas también de qué otras formas podemos colaborar y se puede que esa también es una buena manera bueno no tiene nada que ver con la charla pero bueno debian women yo creo que es un proyecto de actualmente como yo lo conozco ese que en el pasado fue un proyecto mucho más activo que ahora pero ahora lo que quiere ser es un proyecto de de recepción de gente no que es que si tú te sientes que no sabes por dónde empezar pues es una entrada bastante mucho más cálida no quizás que meterte según que lista que hay mucha gente etcétera etcétera mi visión personal de debian women y de que haya pocas mujeres es que las mujeres tenemos que hacer cosas está bien también hablar de hay pocas mujeres hay pocas mujeres hay pocas mujeres pero al final dices en lugar de estar hablando de que hay pocas mujeres vamos a las mujeres a hacer algo y que estemos aquí no y que se nos vea y que y que realmente vemos el callo y estemos haciendo tanto cosas técnicas como traducciones como lo que sea esa es mi visión personal principalmente debian women es un proyecto que está ahí que tiene varios subproyectos dentro y que da la la la mano a cualquier persona más dirigido a mujeres no para de hecho yo también cuando empecé envíe una una carta no decir hola soy mujer quiero entrar porque te da vergüenza no y quiere no sabes por dónde entrar y realmente es un como un portal que tenemos ahí para para poder cerrar romper un poquito esa barrera no perder vergüenzas eso cuesta pero al final algo más bueno ya que estamos hablando este de cómo empezar a colaborar entre los lenguajes los miles de lenguajes que hay de programación vemos a alguien o un grupo que quiere empezar a apoyar qué le recomendarían ustedes qué lenguaje por dónde empezar que le en o sea para aprender un lenguaje es que ya están todos pero quiero decir para empezar a mantener o a corregir errores no no es exactamente los porcentajes de cada hay mucha cosa en c hay mucha cosa en python hay mucha cosa en php hay mucha cosa en java depende depende de lo que te apetezca a ti seguro que vas a encontrar la vía yo creo que hay mucha mucho programa hecho en c eso sí c o c más más pero si tú sabes programar en java en lo que es el empaquetamiento no necesitas saber un lenguaje en particular sí que tienes que saber lo que es un fichero makefile y y lerte como empaquetar un paquete pero no tienes que saber un lenguaje concreto un poco de shell scripting tampoco va mal y aparte de eso claro si no sabes programar en ningún ningún ningún lenguaje pues ponte con uno quizás c te recomendaría para empezar o python también estaré yo le quería decir si mira bueno lo que decía es cierto la la que el castel principal de debia no es programar es empaquetar pero en el tema de programar python es un muy buen lenguaje para empezar por por qué es de fácil lectura porque tiene el intérprete interactivo yo imagino no tengo datos muy fuertes pero mucha de la infraestructura de los sistemas operativos estaba en c y debe seguir estando en c entonces es mucho más complicado pero pero quizás tenga más peso y yo te diría dos cosas en cuanto a en cuanto a programar una hay que tirar mucho código y la otra es parecida a cuando aprendes un lenguaje natural este no no puedes aprender y censurarte al mismo tiempo no se tienes que tener mucha ligereza para para escribir cosas y ver qué pasa no y bueno es realmente tampoco es necesario que tengas un foco muy muy cerrado sobre un lenguaje en particular la cosa es empezar a hacer y tirar código y ver qué pasa no añadiría también que la la ventaja que tenemos es que al ser todo abierto es que a mí cuando lo hablo se me pone la piel de gallina él no lo digo broma porque es que lo puedes mirar todo tienes ejemplos infinitos no para para aprender no porque a veces cuando se quiere aprender tanto a programar como a empaquetar lo que hacemos es coger un tutorial lo sigue está y aquí acabas y dices bueno a ver ahora por dónde empiezo pero es que aquí tienes ejemplos que no te los acabas a veces hasta es lo que puede lo que puede ser complicado es encontrar el ejemplo que te vaya bien a ti no pero bueno no sé si el tiempo se nos ha acabado creo no sé si hay alguien que tenga una última pregunta bueno le agradecemos a mónica por su ponencia cuando os dejo aquí soy las gracias por escucharme si gracias