 Bien, ok, entonces a continuación vamos a tener la charla de Ulysses Vitulli, Derrick. Ulysses es desarrollador de Vian, viene de Argentina, como será obvio muy pronto, y va a hablar de cómo involucrarse en Vian enfocándose al empaquetamiento colaborativo. Por favor, Ulysses. Gracias. Para las conversas, para las personas que están viendo los streams, por lo que esta es una conversa de español. Así que, puedes cambiar. Bueno, la charla es bastante introductoria. La idea es para la gente que tiene interés. De hecho, es interesante porque había empezado por otro enfoque completamente distinto, y me di cuenta que había más interés en empezar a participar que las herramientas de trabajo. Así que voy a hablar sobre las herramientas de trabajo para el final, pero voy a comentar muy rápidamente cómo colaborar y cómo participar. Vamos a ver cómo entra en 45 minutos. Bueno, la idea es, ustedes ya tienen ganas de participar, no hace falta decirles por qué está buena participar en Debian o en cualquier comunidad que aboca el desarrollo colaborativo y software libre. La idea es, como decía usted, ya tienen ganas de participar, y aún no saben cómo. Una de las cosas más comunes que me preguntan es, yo quiero ser Debian Developer. ¿Cómo hago? La realidad es que Debian Developer, me lo había dicho una vez, una Debian Developer hace muchos años, y tenía toda la razón. Del paso de querer colaborar a hacer Debian Developer, Debian Developer es casi necesario. Las partes que se necesitan, o digamos, las capacidades que tenés siendo Debian Developer, las puede hacer cualquier otra persona y no por eso esos más o menos técnicos, no tiene nada en particular más que ejecutar un comando que sube el paquete, nada más. Así que créanme, Ser Debian Developer es al final de todo el proceso y cuando vos decís, ok, la verdad ahora me lleva más tiempo a mí, charlar con esta persona para que lo suba, que subirlo yo, porque yo ya sé exactamente qué es lo que me va a decir esa persona. Así que vamos a entrar muy rápidamente sobre cómo participar, y al final de la charla vamos a comentar cómo una vez que ya tomaron, como se dice, de dónde vengo, tomaron cancha, ya están más o menos adentrados de la participación, cómo entrar a trabajar en distintos equipos, que de hecho para mí es la forma más fácil de aprender y meterse de lleno en el proyecto. Bueno, como decía, una de las formas más directas para participar es reportar fallos. Todos vimos algún fallo alguna vez, muchas veces, y me incluyó todo el tiempo, miramos por otro lado y nos hacemos el tonto porque la falla es humor superfluo o realmente no afecta a la aplicación y seguimos con lo nuestro. La realidad es que el reporte de fallos es importantísimo, incluso lo que ustedes pueden llegar a aparecer, que no es tan importante, es muy importante, porque toda la gente está experimentando exactamente lo mismo. Así que, digamos, en muchos casos el error que ustedes experimentan es muy reproducible a través de toda la gente que usa el mismo software. Entonces, una de las formas es reportar los fallos. Reportar los fallos no hace falta ser un scene engineer, no hace falta codiar bajo nivel. Reportar el fallo es simplemente avisar al mantenedor del paquete, ya voy a explicar bien cómo sería el proceso, pero la idea es comunicar al mantenedor de que hay un comportamiento que no es el que se espera del paquete. Fallos muchas veces pueden llegar a ser, por eso en reporte de fallos hay distintas categorías y distintas literalmente severidades, que es desde está día bueno que este paquete tenga, a esto está totalmente roto, fíjate urgentemente cuando lo puedes arreglar, y urgentemente depende también mucho del software. Outstream, lamentablemente, no es una palabra que pueda encontrar, quizás es una que tiene ese español supertoñado que lo pueda encontrar. Outstream es el desarrollador primario del software. Yo arriba. ¿Cómo? Claro, no tiene sentido. Outstream es el desarrollador o el equipo de desarrollo que es el responsable sobre valer la redundancia el desarrollo del software. Outstream, aunque se confundan a veces los términos, no desarrolla mucho software, desarrolla casi siempre software internamente que le sirven a de bien y después lo liberan, a diferencia de un tú que no lo libera y lo desarrolla igual. Outstream es ese conjunto de personas o esa persona. Muchas veces el fallo ya se encuentra reportado por, por ejemplo, otra distribución o otros usuarios en el sistema de seguimiento de fallos del software. Esto es muy particular y lleva, digamos, un análisis más exhaustivo, o sea, de cómo reportar al Outstream de un software, pero el punto es buscar unos minutos cuál sería el sitio, por ejemplo, vamos a dar un caso, tiene una falla con su navegador, siendo Firefox o lo que sea, ponen en cualquier buscador Firefox o el navegador favorito de ustedes, problema y más o menos tiran una palabra clave para poder llegar a encontrarlo. Si está reportado, el reporte del VAL para Debian es mucho más fácil. ¿Por qué? Porque primero el mantenedor del software no tiene que ponerse en contacto con el Outstream. En Debian, algo que es muy importante y que se trata de forzar a rajatabla es nosotros, sí, a diferencia de un tú de vuelta, contribuimos con Outstream. Nosotros sí mandamos nuestros parches o realmente hacemos nuestro mejor esfuerzo. Yo al menos darlo a hacerlo. Eso es lo que hace que toda la comunidad del software y no solo de Debian, porque acuérdense que el software libre también es más que de Debian, aunque se beneficie de eso y eso es básicamente toda la piedra fundamental del software libre que todos nos beneficiemos del software. Bueno, entonces, como decía, si se encuentra reportado en Outstream. Si se encuentra reportado en alguna otra distribución o vendedor, digamos, la mayor parte de todos los sistemas separativos de una emberredura bastante grande tienen sus sistemas de seguimiento de fallos y es básicamente el mismo proceso que el de arriba, buscar si se encuentra reportado ese error y dedicar un poco de tiempo. Esto a esta vez es increíble que son literalmente dos minutos. O sea, sentarse. Más o menos tratar de ver si se puede reproducir el error y ponerlo en el search box del browser y ver qué sale. Literalmente hay veces que haciendo esa operación está la respuesta de la solución. Obviamente hay veces que la solución es, digamos, por una configuración local. Ejecutamos algo o corremos algo y se soluciona. Pero eso está bueno que el mantenedor lo sepa. Porque si lo puede arreglar, nos beneficia a todos. Incluso aunque sea un problema local. Entonces dedicar unos segundos a reportar los bugs es muy importante. De hecho, es la forma más fácil de contribuir y ahora les voy a mostrar cómo. Voy a tratar de hacerlo rápido porque estamos medidos justo de tiempo. Una de las formas más fáciles es usar un sofro que se llama report-barc-ng, que básicamente lo que hace es abstraer de mucha de la complejidad que en realidad es muy simple cuando ya se entiende o funciona, pero de abstraer cómo funciona el sistema de reportes error. Hay toda una nomenclatura y toda una documentación asociada cómo usar esto bien. Pero la idea es usar herramientas que nos simplifiquen esto y después cuando estamos cancheros podemos reportarlo abriendo directamente un estroclante correo y haciendo el error. Bueno, por ejemplo, primero que nada hay que ver, yo lo puse después, pero me quise saltear esto para que se vea, primero que nada hay que ver si ya está reportado un bug antes de reportar una nueva. Porque la realidad es que Debian tiene una base de usuarios tan grandes que muy probablemente el mismo error que tiene ustedes ya exista y esté en el sistema de seguimiento de fallos. Entonces, por ejemplo, Firefox. Bueno, en este caso esa es Weasel porque Debian tiene su branding. Lo que voy a hacer es buscar en el filtro de Paquete Ice Weasel las fallos. Ahora lo que está haciendo y probablemente no tenga internet, por eso está retanto. Es una posibilidad que no había devolvado. También puede ser la cantidad de paquetes de reportes de fallos que tiene el fallo. Sí, de hecho es un caso... No creo que no tenga ninguno. No, no tengo internet. Bueno, básicamente igual el proceso es exactamente lo mismo. Ustedes ponen acá mientras... Ustedes ponen en este checkbox ponen en este checkbox el software en particular. Hay veces que es medio confuso cuál es el software que puede llegar a tener problemas, pero la realidad es que prueben. Lo peor que puede pasar es que alguien les tire un par de puteadas del otro lado del mundo y no pasa nada, nadie se va a enojar. Además, de hecho, es mucho mejor probar y equivocarse que solamente hablar de si, ahí está. Por ejemplo, ahí es Weasel. Ahí está buscando. Sí tendría a haber buscado un software más chico. Bueno, mientras sigue... O no se conectó. No se conectó. Qué grande. Bueno, no importa. Esto siempre pasa. Es la ley... Exactamente, es la ley Morphe. Pero bueno, muestro un segundito cómo sería el funcionamiento y ahí se colgó. Ah, mirá, está bajando. Bueno, ahora cuando aparezca, lo vemos. Firefox tiene un desarrollo bastante activo. Por no decir, tiene muchos bugs. Bueno, ahora cuando termine lo vamos a ver, van a aparecer detallados los bugs que ya están abiertos, reportados por otras personas. Y hay veces que, digamos, de hecho es una buena práctica poner como título en el reporte de bug qué es exactamente el error que vos ves. O sea, si vos ejecutas algo y explotas completamente el terminal, una línita, poner esa línita como subject o ponerlo como palabra clave, eso ayuda para buscar y las búsquedas se hacen muy rápidas. Por ejemplo, acá hay un montón de bugs, están ordenados por, como pueden ver, están españolas y que bastante bastante amigable. Se puede buscar acá por el tipo de gravedad, pero en este caso vayamos por lo que sería el resumen. Acá está una descripción de cuál es el error supónganse que puede llegar a hacer esto algo parecido a los de ustedes, hacen doble click y va a buscar la aplicación por atrás, el reporte del bug. Si más o menos creen que tiene sentido perdón, si creen que no tiene nada que ver ponen ahí esto es el reporte del bug. Una cosa que no dije es que, si bien para colaborar en devian no es obligatorio saber inglés es relativamente mucho más fácil manejarse básicamente con el inglés. La realidad es que puedes colaborar de la misma forma usando cualquier traductor online o nonline, pero es relativamente más fácil. Desde ya hablar inglés no es un requisito para nada. Si no, dense cuenta de la cantidad de debilidad para que hay acá y que ya hablan inglés terrible. Bueno y esto más o menos es el reporte. No sé si va a llegar a ver, pero la realidad es que todo esto es prácticamente agregado en forma automática y este es el mensaje del reportador del bug de qué es lo que experimenta. Como decía supongase que no existe el bug ahí para la aplicación después me voy a explicar bien cómo se llega esto, pero para que más o menos tengo una idea de cómo se reporta los bugs. Hay una hilerita de conitos así que se llega a ver bien, que dice de un diablito, dice reportar nuevo error, se hace click ahí, va a aparecer probablemente para que salga mi otra pantalla y sí, morfe. Bueno, seamos porque si no. Pero va a salir va a salir una ventana con un menú que van a tener distintas opciones, por ejemplo de la severidad de la falla, probablemente también aparezca ahí ahora. La severidad de la falla, una descripción chiquita de la falla y una descripción más grande ahí donde se llenaría con la descripción del problema. Después vamos bien igual, no tiene mucha o sea es literalmente ejecutar la aplicación y llenar los campos. ReporWagenG es está totalmente tripletizado, o sea tiene almohadillas como se dice correctamente en español, tiene textos para reemplazar y una vez que se reemplaza es completamente directo, es straightforward. Uno llena los campos o las descripciones que le pide la aplicación y lo reporta. Hay que mirarlo detenidamente, antes de apretar el botón sen no tiene mucha complejidad y reemplazar como decía los campos faltantes. Hay mucha información que es muy particular del fallo, por ejemplo si yo abro un cliente de correo y cuando apreto enviar explota, realmente el comportamiento no es que explota cuando lo abro, explota cuando lo hago, enviar. Esos detalles es esencial ponerlo en el reporte de BAG. En inglés malo que tengamos, no importa es esencial ponerlo, después cualquier cosa el mantenedor con un par de alaridos pedirá que le expliquen mejor que es lo que quisieron decir pero lo importante es ser bien descriptivo. Muchas veces y de hecho hay cosas completamente bizarras de reportes de BAGs. Me acuerdo uno que es brutal de hecho también lo contó una persona que conozco en una charla. Un reporte de un BAG de que la computadora se colgaba cuando la madre tocaba el piano una cosa ridiculísima o sea que conexión puede llegar a tener que la madre tocaba el piano y que la computadora se colgase. Bueno resultó ser que la chica este usaba unas placas sintetizadoras de sonido y que capturaba la salida del teclado así que terminaba yendo por ahí imagínense la cara o yo me imaginaría la cara del mantenedor viendo un reporte que dice ¿Se me cuelga la computadora cada vez que mi mamá toca el piano? No, es allá. Es demasiado. Pero bueno, evidentemente se llegó a buen camino y hay realmente una experiencia muy importante en lo que es el reporte de BAG para upstream. O sea, deben sirver como base de datos para también terceras personas el sistema de seguimiento de BAGs debe así como base de datos para otras personas. Esto también es importante para quienes usen testing, porque para estable relativamente esto no pasa seguido muchas veces suele ocurrir que cuando actualizamos un software, voy un poco más rápido porque si no no vamos a llegar con el tiempo. Cuando actualizamos un software o cuando actualizamos toda la distribución notamos que empezó a fallar una u otra aplicación. Muchas veces lo que suele ocurrir no es que la aplicación que estamos usando falla, sino que alguna lidería, alguna aplicación de la cual mi aplicación que estoy usando depende de si tuvo un cambio de comportamiento, tuvo una actualización de versión y nadie se percado todo hasta que llegó a la distribución, a la rama que estoy usando. Entonces detallar bien puntualmente si esto empezó a pasar a partir de alguna situación, por ejemplo renicí la máquina después de 10 meses que no lo hacía y ahora no arranca genome y de hecho es algo valio para decir. Otra cosa que es un poquitito más complicada pero realmente es muy simple cuando se entiende qué es lo que hace. Las aplicaciones tienen y en Unix en general tienen un diseño de la salida de los mensajes. Eso es para la persona que lo usa y para la persona que lo desarrolla y para la que no administra. ¿Qué quiero decir con esto? Al ciertos tipos de mensajes que el desarrollador a propósito escribe en la pantalla para que la persona que lo use pueda llegar a tener una idea de qué es lo que representa el error. Estos errores cuando se lanza una aplicación de por ejemplo un launcher como el que inicia la aplicación es un lanzador y en una terminal esos mensajes no se lo llega a ver. Esos mensajes quedan en el X que es el que lanza las aplicaciones cuando se tiene un launcher. Entonces, o bien, lanzar la aplicación desde una terminal que es tan simple como abrir una terminal nueva desde el menú de aplicaciones, o sea, tan simple como hacer esto. Claro, es tan simple que no funciona. Ah, bueno, eso es porque estaba... Bueno, como tener una aplicación y decir Firefox, que acá creo que no tiene... Sí, ahí está. Me lo va a abrir y ya está. Si esto... Si yo cuando estoy reproduciendo el error hago un clic acá y explota que lindo esplota me encanta la palabra esa. Me estoy dando cuenta que el reloj está... Ah, está. No se movió el reloj. Me ha sido interesante. Es un bug, seguro. Si explota, la salida del mensaje muy probablemente quede en la terminal quede en esto y yo voy a poder copiar y pegar esa información poner en el bug y muchas veces esa información es todo lo que mantenemos necesito para poder reproducir el error. Acuérdense que muchas veces hay errores que son tan pero tan especiales que son muy difíciles de reproducir. Así que tengan paciencia. Bueno, este procedimiento de lanzar la aplicación de una terminal muy probablemente en la mayor parte de las veces que se genere un error o una falla va a aparecer ahí. Bueno, y lo que decía recién, proporcionar toda la información, incluso que le parezca completamente superfluy que no tenga nada que ver de que hice clic en mi cliente de correo y después de tres vueltas a la silla y explotó, hay veces que dar tres vueltas a la silla hizo algo en el comportamiento de la máquina. Pónganlo, es ridículo aclaren que es ridículo, pero pónganlo muchas veces sirve. Esto, muchas veces la gente no lo menciona y es hiper importante. ¿Qué pasa? Hay muchísima gente que reporta Bax. Ojalá fuesen todas, pero partamos de ese hecho. Hay mucha gente que reporta Bax, pero hay poca gente que lo sigue. Hay veces que la gente que lo reporta y eso es muy responsable la gente que lo reporta directamente abre el bag, lo lo envía y nunca más se dedica a responderle al tip al manteneror, que ese intercambio lleva por correo electrónico o sea, no es que hay que estar atento a algo, uno lo lee en su bandeja de entrada. El manteneror necesita información para ver si lo puede reproducir y ustedes no responden o no se responde el bag. Eso es realmente bastante feo porque el manteneror está en una situación en donde sabe que hay un error está tratando de reproducirlo, pero no tiene el flujo para poder resolverlo. Entonces es hiper importante por eso decía, primero busquen si están los errores que ustedes experimentan ya reportados. Es hiper importante hacer seguimiento de los errores que ya están reportados. Tan fácil como decir, todavía me sigue pasando en un bag que lleva más de una semana porque si realmente digo que 30 segundos después del mail de la persona anterior que reportó el bag, digo sí, a mí me sigue pasando y evidentemente es porque estás experimentando el mismo problema pero hay ciertos fallas que son relativamente difíciles de reproducir y lo que ocurre es que a través del tiempo se le deja de retroalimentar. Sigan los fallos, incluso que no se han reportado por ustedes, una de las cosas que ahora voy a mencionar es colaborar incluso con fallas de las aplicaciones que usamos diariamente o de las aplicaciones que nos gusta, es muy importante porque en el software libre hay algo que es muy a veces es problemático pero a veces es muy impulsa mucho que es que la gente lo use a usarlo a usar la gente, los usuarios, un producto hay un doble flujo el flujo de el desarrollador motivado que quiere seguir manteniendo el software y después está el flujo de los usuarios del software que tienen intercambio entre ellos y eso también genera que la comunidad de usuarios, de hecho eso es básicamente de todo lo que se trata esto que la comunidad de usuarios soluciona directamente los problemas y el mantener llega para solucionar el problema y subirlo así que es muy importante seguir las fallas y es muy importante, incluso los bugs que tienen dos años, un año, seis meses o cinco años parado de decir yo todavía sigo teniendo este error obviamente si lo tienen, si no no sirve de nada pero es importante verificar la fecha eso que decía recién, no tiene al mantener o no le sirve que cada cinco minutos alguien le manda un bendy diciendo sí, sigo teniendo este problema sigo teniendo este problema, la idea es que a través del tiempo, si notan que estaba experimentando algo y ya está reportado sigan contribuyendo con la información para digamos tiene dos finalidades una incentivar al mantener y otra decir que realmente el problema sigue por eso es importante checar la última actualización, ser cortés no hace falta decir todas las palabras que se les ocurra para el mantener moverse un poco, de hecho muchas veces tiene un efecto negativo así que no van a resultar muy beneficiados de la situación y además ser cortésimo y moderado en el tono de las conversaciones ayuda a las dos personas ayuda a la persona que tiene ganas de solucionarlo y ayuda a la que no tiene ganas porque la que no tiene ganas, alguien que le pregunta y le que tiene un buen feedback positivo es muy difícil responderle de mal a la gana porque uno queda muy expuesto entonces qué es lo que pasa, al tratar muy bien una persona que incluso a veces no se lo merece por el trato, tenía ese efecto reversivo que da vuelta a la situación dar el suficiente tiempo para responder, esto es lo que decía vuelta de los 5 minutos, cada 5 minutos no tiene ningún sentido revisar esto también es importante hay muchas veces que entre usuarios se encuentra que hay una parte en particular de la aplicación que falla y la corrección de la falla es lo que se llama un parche que es básicamente una modificación sobre el software original y si vos pones esto en el software anda eso es importantísimo si no está reportado en el VTD meterlo para que el mantenerlo sepa que no solamente existe el error sino que alguien ya tiene una solución propuesta quizás no se da mejor, pero le dice que le puede servir el mantenerlo para poder dar un paso inicial o para poder continuar obviamente intentar reproducir fallos muchas veces lo que pasa es que tenemos un software que nos encanta mucho pero tiene un montón de bugs vamos a ver, los bugs nuestros ya están reportados pero hay otros que no hay otros que no experimentamos nosotros y que están reportados a ver si se puede reproducir como decía recién y ahora lo voy a mencionar es muy importante que el software que ustedes usan ustedes lo vuelvan a retribuir esto es una cosa importante la sinergía del software y particularmente el software libre se basa en lo que mencionaba hace un rato el hecho de que haya usuarios usando un software el hecho de que un software se ha usado por muchos usuarios tiene muchos efectos primero lo principal en el desarrollador que tiene intenciones de seguir desarrollando el software no hay nada peor que tener un software que nos gusta y que el desarrollador dijo la verdad me aburrí de mantenerlo y no se puede usar más porque se desintereso y el paquete se borró del árbol paquetes a mí me pasó por ejemplo con un paquete y es realmente muy triste entonces tengan la iniciativa de chequear si el software tiene una nueva versión disponible para poder informarle muchas veces los manteneros y sabemos de esto pero la impulsión es que ya che hay una nueva versión la puedes poner impulsa aunque no lo puedan creer a que el mantenedor y el desarrollador porque al fin y al cabo el desarrollador nota que la base de usuarios es importante se se motive voy a ir un poco más rápido que es la verdad bueno y qué es lo que tiene las nuevas funcionalidades importante para la contribución el software las nuevas funcionalidades las mejoras y las nuevas funcionalidades y los fallos de errores es importantísimo para lo que también estaba mencionando recién la sinergía que hay entre los usuarios y el desarrollo la experiencia de usuario con nuevas funcionalidades experimentándose muy seguido hace que primero un software tenga una un efecto positivo sobre los usuarios yo me sienta bien por usar este software porque la verdad todo el tiempo se están metiendo cosas nuevas y me gusta probarlo eso tiene un efecto muy importante a nivel desarrollo y a nivel comunidad de usuarios si yo uso un software que la verdad provee lo que yo necesito muy básico y hay otro que es mejor obviamente yo voy a usar el otro que es mejor entonces como decía mantener esta sinergía entre los usuarios es importante notificando al mantenedor que hay creaciones nuevas disponibles estamos haciendo un granito de arena para esto de impulsar desde el lado del desarrollador el interés por seguir colaborando revisar si hay fallos o sea lo mismo del lado de deviant del lado del desarrollador voy un poco más rápido porque si no se van a se va a quedar atrás para colaborar y acá es donde vamos a entrar más en la parte de desarrollo colaborativo y herramientas para empaquetar es los paquetes que son huérfanos hasta ahora tengan en cuenta que yo abre muy poco de colaborar técnicamente y ojo que para colaborar a deviant no hace falta ser técnico hay muchas formas para colaborar y de hecho hay muchas que devian careces por ejemplo o que tiene muy poca actividad me da mucha pena decirlo pero hace poco pasó de hecho unas semanas que el arte gráfica que se decidió para implementar en wixic es la versión estable que va a salir de la deviant en unos días tuvo relativamente muy poca relativamente no tuvo bastante poca contribución o retroalimentación de los usuarios y se eligió de las lo que es el arte gráfica a la mayor parte de todos los usuarios que yo pregunté no lo gustaba entonces muy probablemente de hecho yo conozco una persona que estoy tratando de pokearla a ver si la puedo comenzar colaborar desde el punto de vista por ejemplo de arte gráfico es importantísimo para deviant es importantísimo desde el punto de vista promocional desde el punto de vista de usuario yo me siento como me gusta lo que estoy viendo lo que estoy usando a cual se que debían siempre es lo haces vos es tan lindo como vos lo querés hacer o es tan feo como vos lo querés hacer pero siempre hay una cosa asociada que la instalación por efecto las cosas por efecto son bonitas entonces la gente por efecto tiende a dejarlo como está y decir si me gustó la verdad lo instalé me gustó lo estoy usando no me pareció agresivo como decía pasó esto de que realmente mucha oferta por poner algún nombre de arte gráfica y se eligió una arte gráfica que la mayor parte de la gente no le gustaba o al menos la que yo les pregunté no le gustaba entonces realmente como decía no hace falta ser técnico para colaborar las personas de hecho esta herramienta para subir arte gráfica era literalmente crearse un usuario en una aplicación decir tomar esto es la arte gráfica que yo quiero diseñar que yo diseñé que yo querría evaluado para poner en Debian y obviamente tener una licencia que permita el proyecto distribuirlo y tan siempre como eso es, ustedes ya están colaborando entonces tengan en cuenta que no hace falta ser 100% técnico o tener un background técnico para poder colaborar en Debian yo la charla encaro por el punto técnico porque originalmente era la temática pero tengan en cuenta eso una de las formas de colaborar técnicas y ahí me estoy metiendo más rápido es analizar los paquetes workflow los paquetes workflow no son un tipo de de paquete que muy probablemente pueda no ser perdón muy probablemente pueda no ser no estar muerto o sea no no tener un upstream, un desarrollo que está completamente parado sino que la persona que lo mantiene en Debian se desvinculó de Debian o por ejemplo pasa veces que los desarrolladores dicen realmente no tengo tiempo para colaborar quisiera que me remove el proyecto y a partir de este momento todos estos paquetes los orfaneo no es muy español pero bueno lo que ocurre ahí es que un software existe tiene una base de usuarios, se usa y no hay nadie que se haga responsable del paquete entonces por qué esto es importante y por qué está primero en la lista de cómo colaborar los software que ya existen y que ya están y que están orfaneados muchas veces requieren increíblemente poco trabajo porque ya está el software andando lo único que necesita es tener tener interés de alguien para solucionar los bugs o para hacerse cargo de una de las cosas que pasa más seguido es que el software sigue andando pero las librerías las aplicaciones que necesita para funcionar obligan a que el software se tenga que reconstruir una cosa que es tan fácil como decir encontrar un mail a volver a construir esto necesita de alguien que se haga cargo ente bien hay un equipo que se hace cargo por efecto de esto pero la realidad es que tienen tanto trabajo que aunque no puedan creer que cada uno agarre un paquete orfaneado realmente le sirve mucho y además primero y principal es una forma de colaborar muy simple es una forma de ver lo que ya existe, ver ahora yo lo voy a describir acá de hecho voy a pasar un poco más rápido 10 minutos como decía una forma muy fácil de colaborar viendo lo que ya existe, analizando lo que ya está y decir ok yo me voy a intentar hacer cargo, acuérdense que en Debian hay mucha gente que está dispuesta a ayudarles a arrancar yo soy uno de ellos de hecho tengo la mayor parte de toda la contribución que hago en Debian es esponsoleando paquetes de otras personas y es la parte más divertida de hecho bueno estos son las cosas más o menos se estaba mencionando hay veces que también el software que está orfaneado tiene un desarrollo parado es un análisis particular pero vale la pena ponerlo ahí presten la atención al software esto de ver que software podemos adoptar para mantener, está en una lista que es muy fácil de es una lista literalmente de 4 o 5 scrolls completo de pantalla que están orfaneados, muchos son recientes de hecho esto es completamente periódico casi todos los días en todas las semanas existen paquetes que se marcan como orfaneados o como huérfanos que es la expresión bien y lo único que hace falta como decía es buscar a alguien que quitarle un poquito de amor a ese paquete y finalmente y llegando para el final de la charla la parte técnica que estaba tratando de dar hincapié inicialmente pero que me pareció más importante arrancar por esto empaquetar un software nuevo muchas veces y de hecho todas justo hoy estamos teniendo una charla con desarrolladores acá en la conferencia la totalidad de las veces en mi opinión y muchas veces para el resto se aprende muchísimo muchísimo más de leer lo que otros hacen a nivel estructura de paquetes o a nivel incluso de desarrollo que sentándose y tratar de romperse la cabeza de cómo funciona primero por qué porque otra persona ya lo hizo sabe cómo funciona o al menos está funcionando segundo porque hay mucha mucha oferta de paquetes para poder usar y aprender o sea deben tener una cantidad de paquetes que es increíble y es realmente muy fácil de ver el source para la página Debian, packages.debian.org buscan un paquete en la página esa le dice cuál es el source bajan el source y ya lo pueden ver no tienen que hacer más que tres clicks y ya están viendo el código fuente del paquete y del software entonces analizar y revisar y auditar auditar en el sentido de mirar con mucho detalle un paquete es realmente una de las formas al menos para mí fue la forma más directa de aprender cómo ser un empaquetador o cómo empaquetar cosas o a ver cómo otra persona solucionó el mismo problema que yo estaba teniendo una de las cosas que que es más fácil o que hace más fácil el proceso de mantener un nuevo paquete es ver software de características similares por ejemplo yo mantengo este software que es un intercambiador de temas de GTK y hay otro software que era relativamente parecido pero que era de GTK 1.2 una versión anterior y realmente de hecho este fue el primer paquete que mantuve hace ya varios años que empecé a mantener perdón y realmente era prácticamente cambiar prácticamente cambiar el nombre del paquete un par de cosas más obviamente la licencia que tenía características distintas y construyó obviamente de ahí a que entre había un par de modificaciones más pero en una hora en 20 minutos un software de una característica similar el paquete para un software nuevo, era completamente nuevo y realmente salió mirando el otro después uno se sienta se sienta con tranquilidad y empieza a ver que es cada cosa pero al menos ya tiene algo para poder empezar oops esto es bastante técnico y lo voy a pasar un poco por arriba los software que se compilan en general todo lo que es Python, Perl y Ruby esto no cumple entre comillas ahora voy a decir por qué pero tienen formas de generar la aplicación para ejecutarse eso a veces cambia mucho de paquete a paquete y es importante ver software que tiene cada edad de construcción o sea que la forma en que se hace el binario es distinta mirando como hay otros paquetes de vuelta que están hechos de forma similar bueno paquetes de política similares esto es básicamente si yo tengo un software que ni siquiera es igual pero que usa cierto recurso y yo sé que otro paquete que tiene ese recurso mirar ese paquete que tiene ese recurso en común para los dos y ver cómo hace esa persona para solucionar el problema esto es como incorporarse equipos de trabajo o digamos la opción como se puede llegar a ver allá no se entiende nada porque hay una cantidad infernal de equipos para poder colaborar esto es equipos de trabajo que ya existen y en los que se puede colaborar muchos de ellos son relativamente integrados o de poca cantidad de personas pero muchos son enormes por ejemplo Per Team o Python Team o Java Team son equipos que mantienen 500 200 2000 paquetes son equipos en donde realmente colaborar hace bien y ahí en esos equipos aunque a mí no me gusta Per hay gente que tiene muy buena voluntad 5 minutos tiene muy buena voluntad para hacer el ojo tiene muy buena voluntad para ayudar a novatos y de hecho hay gente que tiene paciencia que a mí a veces me falta así que no tengan miedo de ver cómo colaborar en Debian esto es una lista de una cantidad de proyectos o de equipos de trabajo que es solo para que quede documentado esto es una revisión muy rápida que la tengo que hacer en un minuto de algo que habló Gunnar si tu charla de cómo están formados los paquetes voy a ver muy rápido porque tengo que hacer nada básicamente se puede llegar a leer ahí el usuario trabaja con paquetes binarios es un paquete mucho más es un paquete straightforward que solo se instala no tiene fuentes no tiene forma de modificarse sus cadenas de construcción y el desarrollador trabaja con el paquete fuente que decía que entrando a packages.debian.org lo pueden bajar haciendo dos clics uno para entrar a packages.debian.org y otro para hacer el click and search nada más las diferencias de estas cosas todas se descubren mientras se va caminando, no hace falta leerse manuales y enciclopedas de 800 páginas para poder empezar a mantener un solo paquete la forma más simple de empezar a a colaborar es ver lo que otros ya colaboraron y lo que mencionaba hace un rato de ver software de caracterismas similares para poder aprender relativamente más fácil, obviamente puedes mirar todos los paquetes que existen pero te va a llevar más tiempo bueno, esto es un poco la estructura de paquetes y una de las cosas que lo voy a dejar para el final como para que esté y para que no me insulten porque la charla no tenía nada que ver con el título es que tiene que ver git y tengo cuatro minutos así que vengo perfecto pero mi relajo dice cuatro y yo mantengo ese software que dice ntp así que le creo a eso mentira no le creo pero bueno bueno quienes de ustedes saben que es git? buenísimo git es una herramienta voy a mencionarlo para los otros git es una herramienta que nos permite hacer muchas de las cosas que estoy mencionando ahí y otras más es imposible que una charla se pueda hablar de todos los beneficios que tiene git pero básicamente llevense esta idea con git ustedes lo que pueden hacer es mantener una historia de cualquier cosa incluso software puedes hacer documentos repartidas en forma distribuida o sea todas las personas podemos tener la misma información y internamente está construido para hacer fiable y segura de que si yo digo tener esta versión realmente todos tenemos esa versión o sea internamente tiene muchos cheque de integridad para que eso no para que vos le creas que si eso es así es así y desde el lado de debían hay algo que es increíble que yo conozco el 30% nada más y ya me huele la cabeza es usar git para mantener estructuras de paquetes git tiene la concepción voy a meter muy rápido sobre esto la concepción de branches o sea ramas de trabajo bueno ramas no es la palabra correcta mas o menos imagines así todas las ramas son posibilidades o divergencias de un software a través del tiempo por ejemplo el software que está en testing muy probablemente tenga cosas en común con el software estamos hablando del mismo paquete tenga muy probablemente la misma fuente común o en una parte de la historia en común con el paquete que está en estable porque es el mismo software que tuvo modificaciones a través del tiempo y no cambió 100% solo genome cambias un torba de 600% entonces que es lo que pasa primero la una de las capacidades que nos da git a nivel eficiente es mantener la historia de todo un software en un solo lugar poder intercambiar poder trabajar colaborativamente con otras personas intercambiando parches de una forma muy sencilla los dejo ahí para que más o menos se los lleven en la cabeza cherry pick por ejemplo son básicamente herramientas que nos simplifican mucho mucho mucho si, no hay más tiempo leo la otra línea y ya está que nos simplifican realmente mucho el trabajo en Debian realmente es eficiente realmente es muy rápido realmente tiene seguridad metido tiene muchas capacidades que están muy buenas tener y que se los tiro como para que lo vean es una herramienta que está muy buena no solo para Debian y que encima en Debian conociendo la herramienta en Debian la pueden usar de una forma muy interesante lamentablemente nos quedamos sin tiempo y queríamos tratar cosas pero preguntas muy de hecho que dos minutos y una tipe no funciona todos lo saben no voy a hacer comentario sobre eso preguntas perfecto tenemos que portar eso por solicitud de nuestros por solicitud de video de hecho bueno ahora sí estoy sobre el minuto bueno gracias por venir y realmente colaboran porque es algo que nos beneficie a todos bueno