 Olá todo mundo, meu nome é Ellen, eu trabalho numa empresa chamada Colabora, sou desenvolvedora. Eu queria pedir perdão aqui porque os slides estão em inglês, que eu fiz essa palestra no passado, mas enfim, eu vou falando, espero que isso não tenha problema no entendimento da palestra. Então, o objetivo dessa palestra é ser um guia para quem está começando. São informações que eu achei interessante quando eu estava começando, que eu acho são informações espalhadas por vários lugares e foram úteis para entender o débil como um todo, e eu espero que seja útil para vocês também. Então, do que a gente vai falar? Então a gente vai falar sobre a organização da comunidade, o que são os chamados Foundation Documents, documentos de fundação, quais são as versões, o débil, as releases, como a comunidade trabalha, o que é o bug tracking system, o sistema de rastreamento de bugs, como contribuir, algumas ideias aí de como contribuir, bom, mas a maioria acho que foi coberta aí no painel de manhã, e um pouco de débil e o bunto, como os dois relacionam. Então, uma introdução aí, o débil foi criado, a primeira versão foi realizada em 1993 por um cara chamado Ian Murdock. E na época, não sei se era namorada, se era mulher dele, agora não me recordo direito, se chamava Débora. Então, o nome do débil veio do nome dele, Ian, mais o nome da Débora, então Débora. O débil, ele suporta oficiais, nove arquiteturas, só que tem outras lá no repositório que são suportadas não oficialmente ou parcialmente. No débil nós temos mais de 55 mil pacotes e mais ou menos mil desenvolvedores oficiais que fazem parte do projeto oficialmente. Depois eu vou explicar melhor o que é fazer parte do projeto oficialmente aqui. E o débil é free software, e a gente vai explicar melhor o que é considerado free software no ponto de vista do débil. Certo, então a organização, a organização é uma coisa bem democrática, ela é diferente de vários outros projetos, porque nós temos um líder de projeto e que ele é eleito uma vez por ano. Todo mundo é voluntário, então nós somos uma organização 100% feita de voluntários, é lógico que tem muita gente que trabalha porque uma empresa tem interesse, mas a teoria ali, todos são voluntários, certo? E a comunidade, ela é dividida em times, times de trabalho. Então nós temos, por exemplo, um time de, está meio pequeno ali, mas é o time de DSA, débil no sistema administrators, são os administradores da infraestrutura do débil e aqueles que cuidam das máquinas, que rodam pelo mundo, que estão lá, onde estão a infraestrutura, onde estão os pacotes e diversas coisas. Temos o time de FTP Masters, que vamos falar um pouquinho mais depois, que é a galera que verifica os pacotes e aceita eles no débil. Temos o time de releases que eles organizam, cada vez que solta uma nova versão do Debian, eles fazem, eles organizam todo esse processo, o time de Debian CD, aquele que vai gerar lá o CD bonito para vocês baixarem o salário do Debian, time de segurança, time de controle de qualidade, e tem centros outros times que você podem dar uma olhada na Wiki sobre os outros times. Então, o que eu quero dizer, assim, com 100% voluntário, certo? Significa que nós não somos uma organização voltada a lucro, que não tem uma organização voltada a lucro por trás da comunidade, que não é o caso, por exemplo, de outras comunidades, no exemplo do Ubuntu, que tem a Canonical, da Fedora, que tem a Red Hat, que faz parte da Board. Só que quem é que é dono, então, das máquinas, da logo, da trademark do Debian? Então, para isso, nós temos os nossos sponsors, que são essas empresas que são as donas legais dessas coisas, e o nosso principal sponsor é o SPI, que é o Software in the Public Interest, é uma organização que foi criada justamente para coletar as doações que as pessoas davam para o Debian e também para ser dona da logo-mark, da trademark. Ela não é a única sponsor, temos outras, temos outras organizações que doam as máquinas para a gente, mas essa daí é uma organização não voltada a lucro, que foi fundada em 1997 para receber as doações. Certo, então, o que são os chamados Fundation Documents? E são, na verdade, o que define os princípios e guia comunidade? Então, nós temos principalmente três documentos principais, então, temos o contrato social, que ele vai definir os princípios morais da comunidade. Temos o Debian Free Software Guidelines, que vai definir o guia do que é o Free Software no ponto de vista de Debian, também conhecida como DF-SG, e em termos a constituição do Debian, que define como a comunidade organizada, como a gente toma decisão, sendo uma comunidade 100% voluntária, a gente ainda tem uma organização. Então, o contrato social define? O contrato social define que o Debian vai ser 100% livre, e que a gente vai devolver as coisas que nós produzimos de volta para a comunidade de software livre. O que significa que, se você é um empacotador, você achou um bug lá no projeto upstream que você está trabalhando, você pode fazer, corrigir esse bug e colocar no Debian, mas a gente é incentivado você a enviar esse bug de volta, essa correção de volta para o software upstream. Então, você sempre está contribuindo de volta para outros projetos no mundo de software livre. E a gente não vai esconder problemas, a gente vai deixar eles claros para todo mundo e tentar resolvê-los. A nossa prioridade são os usuários e são software livre, e também nós temos trabalho que não faz parte do que não são considerados software livre, a gente também dá um certo suporte. Então, nós vamos ter uma estrutura, que eu vou explicar um pouco mais tarde, de software que não é considerado software livre, mas ainda a gente vai dar uma infraestrutura para colocar isso no repositório e dar um certo suporte, que eles podem ser software livre, mas que eles não fazem parte da definição Debian de software livre, certo? Agora, o que é o software livre para o Debian? Então, esse documento, na verdade, faz parte do contrato social, ele é meio que um anexo lá, e ele define o que livre significa. Então, o que é livre? Que é livre de redistribuição, que a gente tem acesso ao código fonte, que podemos fazer trabalhos derivativos, que a gente não discrimina contra pessoas ou grupos ou lugares, por exemplo, tal software pode ser usado no Brasil e não pode ser usado na Alemanha. A licença não pode ser específica para o Debian, por exemplo, ah, beleza, esse aqui é, sei lá, licença de IPL, mas só para o Debian para as outras não, não pode isso. E não pode contaminar outros softwares assim, que, ah, eu tenho uma licença que obriga, para eu usar, obriga que o outro software acelar biblioteca que ele depende, seja de alguma certa licença. E, por exemplo, a licença de IPL, a licença BSD, a licença artística, elas são consideradas parte compliance, que são de acordo com a DFSG. E a constituição do Debian, ela define a estrutura e como a gente toma decisão aqui na sua organização, certo? Então, nós temos os desenvolvedores de Debian, que a gente chama Debian Developers, né, DD, desenvolvedores Debian, que são realmente, assim, membros oficiais do projeto. Eles têm direito a voto, eles têm direito a votar, não só para a pessoa, pelo líder do projeto, mas eles têm direito a votar pelo chamado... Amendement, se não me engano agora, que vamos supor, os desenvolvedores não estão concordando com o que o líder do projeto estão fazendo, então eles fazem um documento para tomar alguma outra atitude e todo mundo vota. E, se isso passar, eles podem sobreescrever a decisão do líder do projeto. Então, nós temos um líder do projeto em si, que é eleito Mavis Purano, como eu comentei. Nós temos um comitê técnico, e o chair, meio que o cabeça do comitê técnico, que eles estão lá mais para... Vamos supor, nós tivemos conflitos entre várias partes do Debian, e aí ninguém está chegando em um acordo, assim. Então, você pode chamar eles para resolver esse conflito, ou, se você não sabe direito como resolve alguma coisa, vocês podem contactar eles para saber como é que resolve essa coisa. E, então, eles são mais para conselhar, mas eles também são para tomar alguma decisão. Por exemplo, enfim, nós temos dois grupos, um grupo que é alguma coisa e outro que é uma coisa posta, e aí vem o comitê técnico para tomar essa decisão. Certo? Nós temos pessoas que são apontadas pelo líder do projeto para alguma tarefa, o líder do projeto tem várias coisas para fazer, então ele nomeia alguém, você vai cuidar dessa tarefa. E nós temos o secretário do projeto, que é a pessoa que organiza as eleições, e também ele, junto com o chair, podem ficar no lugar do projeto que o líder casa, e ela acontece alguma coisa com ele, caso ele não possa responder, certo? Então, o projeto que lida é atual, que nós temos, é o Chris Lamb, e ele provavelmente vai ser o próximo desse ano, da próxima leição, porque, até onde eu vi alguns dias atrás, ele era o único candidato. Não sei se outras pessoas candidataram aí, na semana passada que eu não acompanhei, mas ele era o único candidato. E a gente, ele vai ser o líder do projeto novamente. Então, se vocês quiserem saber melhor o que esses poderes, o que eles fazem exatamente, tem ali esse documento na internet, no debiom.org.devel.constitution, que ele define exatamente todos os processos, como faz a votação, como faz essa tomada de decisão. Ok, pacotes e releases de versões do Tab, como a comunidade trabalha. Certo, então, o que é uma distribuição? Quando a gente pensa em distribuição, na verdade, a gente pensa, simplesmente, o que a gente chama de root.fs, é o seu... é a sua pasta principal do seu sistema, seu barra lá, certo? Que é simplesmente um conjunto de arquivos e pastas. Então, quem, lógico, que vai ter o core do sistema, o linux kernel, que ele é simplesmente uma parte disso, o nosso sistema é guinolinux, o conjunto inteiro, e o linux kernel, ele assume muito pouco sobre o que tem nessa nossa pasta principal. Ele é basicamente, assume que vai ter esse arquivo chamado barra sbin, barra init, nesse caminho, que é o primeiro programa que ele vai inicializar para poder inicializar o espaço de usuário, basicamente. E, então, na verdade, ele assume pouco. E, então, isso quer dizer que nós temos que uma distribuição simplesmente define todo esse conjunto, toda essa estrutura de pastas e arquivos que vocês veem quando você está ao seu sistema. Então, uma distribuição é basicamente essa imagem aí, e podemos ter outras distribuições. Quando eu falo que o kernel assume pouco, quer dizer que cada distribuição é livre para se organizar da maneira que quiser. Então, o barra sbin, barra init, inicializa o user space, e uma distribuição também vai ter um conjunto de programas e caminhos bem resolvidos. Porque quando você tem um programa que precisa de outra para executar, ele precisa achar esse programa no sistema. Então, a distribuição assegura isso para você. E também, uma distribuição, principalmente a distribuição baseada em Linux, provavelmente tem, que é, no caso do Debin, uma definição de formato de pacote. O que é um pacote? Como foi explicado no painel de hoje de manhã, um pacote, falando uma parte mais técnica, ele é simplesmente o nosso software. Vamos supor, o GIMP, que é um editor de imagem, ou VLC, que é o que você escuta música. Alguém fez lá, mas não necessariamente fez para o Debin. Então, o pacotador vai pegar esse software e vai colocar várias metas informações para que o sistema saiba como instalar ele de mais fácil. Então, a instalação é mais fácil de distribuição para as pessoas. Então, nós temos dois tipos de pacotes, certo? O pacote source, o pacote fonte e o pacote binário. O pacote source, ele define como buildar, não sei qual seria a tradução de build, construir, compilar o pacote original. E o pacote.debin, ele já tem lá todos os binários para você. É fácil você instalar, ele só copia os arquivos para o lugar certo do sistema e tudo vai funcionar bonitinho. E nós temos também uma ferramenta desse pacote, que é o por baixo, é o dpkg mas vocês provavelmente usam o apt para instalar o pacote, certo? E além disso, a distribuição, ela fornece uma estrutura de repositórios para manter esse pacote. Vocês têm que baixar esses pacotes de algum lugar, entendeu? Então, nós vamos ser um conjunto de servidores, um conjunto que a gente chama de mirrors, que são simplesmente outros lugares que fazem copy desses pacotes para você conseguir baixar eles mais rápido, não é? Você não quer baixar um pacote que vem do Japão, senão pode demorar muito. Enfim, nós temos o nosso manager de pacote no Debian, que é o apt. E você pode pensar um ponto de vista do Debian, de uma distribuição é que tudo na verdade é um pacote e todo arquivo que você tem dentro do Debian se você tem comando lá que é dpkg-s, você consegue colocar o arquivo, você vai ver que todo arquivo dentro do Debian é parte do pacote. Quando você instala ele, tem vários arquivos que já vêm lá para o default, mas é porque alguém já botou os pacotes lá quando criou aquela imagem. Então, basicamente, o workflow da comunidade é fazer essa administração de pacotes, certo? Ver quais pacotes vão entrar, como empacotar, verificar se esses softwares estão na licença correta e etc. E você pode instalar o Debian através das imagens de instalação de CD que é uma que vem com várias ferramentas e já com um set específico de pacotes para você. Então, basicamente, você pode ver que a dinâmica da comunidade se baseia em duas coisas. Tem uma micro dinâmica e uma macro dinâmica. Eu vou falar da micro dinâmica por enquanto. Então, a micro dinâmica é uma administração por pacote. Então, você vai ter lá o mantenedor do pacote, certo, que vai cuidar, que aquele pacote se integre, ok, no seu sistema. E, ou, esse pacote pode ser administrado, na verdade, não por uma pessoa, mas por um time de desenvolvimento. Então, às vezes, o pacote é muito grande, dá muito trabalho, então, eles se organizam em times para cuidar daquele pacote, certo? E, também, além disso, dentro do pacote vai ter uma dinâmica de pessoas que vão enviar correções, vão enviar pets, vão fazer... outras pessoas vão revisar esses pets, vai ter os mantenendores vão fazer update, tem outras pessoas vão testar, outras pessoas que vão aplicar correções de bugs e outras vão precisamente falar, ah, tem um bug ali, tá aí tô te informando, né? Então, essa é a micro dinâmica principal dentro da comunidade. E a macro dinâmica aqui é controlar o que que entra nos repositórios, certo? Então, quais pacotes vão para quais repositórios, né? E quem tem acesso a essa infraestrutura as versões em si, né, tem que fazer uma administração dessas versões a administração dos serviços que nós temos, das licenças, né? Se o software faz parte ou não segue o DFSG e e também controlar, é... distribuir uma forma das pessoas instalarem, né? Que as pessoas podem instalar em... Você poderia instalar o Debi na mão, pegando pacote para o pacote lá, copiando colando, mas assim, não é muito prático, certo? Então, as pessoas preparam um... mais... de instalação, ou você pode também usar uma ferramenta chamada VM Bootstrap que ela gera para você uma imagem principalmente para a máquina virtual ou usar o Live CD para testar. Beleza, então quais versões a gente tem? Então, o nome das versões são baseadas em... personagem do Toy Story Então, nós temos três versões principais do Debian Nós temos o Unstable que também é conhecido como SID Nós temos... que é a versão não estável, né, Unstable é Testing que é o Buster atualmente que ele vai ser o futuro Debian 10 e o Stable que é o Stretch, que é o atual Debian 9 Certo? E... o que é o Repositório, sabe? O Repositório, na verdade é apenas um... um centro de um pacote de uma determinada versão Então, quando eu vou falar aqui de Repositório do Unstable, estou falando dos pacotes que fazem parte da versão Unstable, Repositório do Stable, as pacotes fazem parte de a versão Stable, mesma coisa para o Testing, certo? Mas, além desses Repositórios principais nós temos outros Repositórios que é o Experimental que ele não é uma release completa é só... vamos supor, você quer antes de mandar isso realmente, oficialmente para o Debian, você quer pedir para quem revisar aí você manda isso para lá Temos o Old Stable ou o Jesse, que foi o depromovido para o Stable temos o Repositório de Backport, quando você pega uma um pacote de do Unstable, por exemplo e coloca ali para funcionar no Stable e... e é isso que... Certo? Então, como é que você define da onde que vem seus pacotes, certo? Você pode usar o CD de instalação que é... que você tem uma imagem lá para você fazer o download instalar o Stable eu acho que tem uma imagem para o Testing também se eu me lembro bem e... só o Unstable que não tem uma imagem, porque, enfim ele é muito instável, a gente vai explicar melhor o que é... qual a diferença desses dois logo mais e... porque o Unstable ele é muito assim, todo mundo está colocando pacote novo lá todo dia, então, não tem como gerar uma imagem assim para você vim instalar o Unstable Certo? E aí você... simplesmente para você conseguir definir da onde vem os seus pacotes, você pode editar um arquivo que é no barra tc, barra apt, barra source e lá você vai definir o... o tipo, está meio pequeno aí é... você vai definir o tipo de pacotes que você quer pegar de um determinado Repositório, se é DEB SOURCE, ou seja, aonde ele vai pegar os seus pacotes binários, aonde ele vai pegar os seus pacotes SOURCE você define o MIRROR que é o servidor, aonde você vai fazer esse download dos pacotes e você define a versão, no caso ele está escrito stretch e você define as seções, então nós temos três seções, a main, a contribe e a non free que eu acho que eu vou falar um pouco melhor aqui no próximo slide depois que você edita isso aí, você só dá um apt-get update para ele baixar a lista de pacotes que fazem parte de aquele Repositório e um apt-get upgrade para ele mudar todos os pacotes que você tem no sistema para os pacotes que... da versão que tem nesse Repositório, certo? Então, por exemplo, se você quiser baixar tem um pacote realmente chamado Hello, DEB se você quiser baixar o código fonte do Hello, você dá apt-get Hello, apt-get SOURCE Hello e se você quiser instalar o pacote Hello, você dá... você digita na linha de comando apt-get install Hello, certo? Então, só para analisar a estrutura desse arquivo, acho que aqui talvez dê para ver um pouco melhor então, na primeira coluna, a gente define se é um pacote binário, um pacote source na segunda coluna, a gente coloca o endereço do MiHor do servidor, da onde a gente quer baixar os pacotes e no terceiro é a release, a gente pode colocar a stable jesse unstable test qualquer um desses ali e a sessão ali na release você pode colocar... vamos supor que você colocou a stretch, certo? Stretch é a nossa versão estável que é a atual stable, certo? Só que quando na próxima vez que a gente fazer uma release da nossa... próxima versão stable vai mudar, não vai ser mais o stretch que vai ser a nossa versão stable, vai ser o bustle que eu vou explicar melhor um pouco mais na frente se você colocar stable, você vai sempre estar acompanhando a versão estável então, quando outra release stable o seu sistema vai mudar todo o pacote para o novo agora, se você colocar só o stretch, ele vai continuar no stretch ele não vai fazer esse upgrade, certo? uma coisa que eu esqueci de comentar o nome seed, que é para o unstable ele vem, que é um personagem Toy Story, que é bem interessante porque a versão unstable e o personagem seed é aquele moleque que fica quebrando os brinquedos então, é um nome bem apropriado, porque é uma versão não estável e o legal também da siga seed é que você pode interpretar como still in development é bem apropriado o nome da versão não estável, certo? e ali, a gente tem as sessões então, como eu falei antes o Debian ele tem a definição do que é livre para o Debian só que nós também damos uma infraestrutura para outros softwares que não saem 100% a DFSG então, quando você coloca ali a sessão main, escreve main é o que faz parte do Debian então, você só vai usar pacotes que seguem a DFSG agora, o contrib eles também seguem a DFSG mas ele, quando você coloca ali a sessão contrib, mas os pacotes na sessão depende de algum pacote que não são livres e a sessão non free é uma sessão de pacotes que não são livres que não seguem a DFSG certo ok, que é o que eu acabei de explicar então, a main ela faz parte do DFSG e todas as dependências dela também fazem parte do DFSG o contrib e algumas dependências não são algumas dependências não fazem parte e o non free não fazem parte da DFSG e nós consideramos que eles não fazem parte do Debian mas damos uma infraestrutura pra eles mesmo assim porque gente é legal certo, então agora eu pretendo explicar pra vocês o que que é um stable exatamente o que que é o teste o que que é a versão estável então, vamos lá nós temos o nosso desenvolverador do Debian que ele faz um pacote e ele envia esse trabalho para o Debian e quando ele via esse pacote primeiro ele não vai cair na versão estável certo, porque a versão estável é feita pra ser estável para funcionar sempre, se você enviar qualquer coisa pode ser que quebre, pode ser que dê um bug e nada mais funcione então, a ideia é quando você envia um pacote para o o Debian ele vai cair primeiro na versão não estável vai ficar ali um tempo que de quanto tempo ele vai ficar lá e aí depois que ele seguir alguns requisitos ele vai ser emigrado automaticamente para nossa versão testing meio que vai ser copiado ele vai estar meio que nos dois e quando nós temos uma uma release de uma nova versão estável que acontece mais ou menos de dois em dois anos então, a versão testing todos os pacotes da versão testing vai ser promovidos para o estável certo, e além dessa então, esse é o workflow principal da comunidade e como é que o seu pacote navega entre as versões além disso, nós temos o experimental como eu comentei que é quando você quer que alguém verifique o seu pacote então você não envia para as versões especiais do Debian e envia para um outro repositor experimental onde as pessoas conseguem baixar e verificar certo então para resumir assim como tudo funciona, então nós temos lá em cima também o pequeno mas nós temos o autores pre-string vamos pôr o cara que escreveu o VLC o seu player de música ele faz uma nova versão eu venho do desenvolvedor Debian pega sua nova versão e empacota ele quando ele empacota ele faz um pacote de fonte ele cria ele compila um pacote de binário e ele envia esses dois pacotes para uma máquina que se chama FTP Master que é onde o time de FTP Master vai verificar se esse pacote segue a DFSG se está conforme se o pacote está como como deveria ser e aí que é essa máquina aqui nesse quadrado azul é o FTP Master, o nosso servidor de pacotes e lá seu pacote vai cair no não estável quando ele for aceito você tem um serviço automático que são os auto builders você nós suportamos nove arquiteturas oficiais e então o que vai acontecer automaticamente esse pacote vai ser enviado para diversas máquinas diversas arquiteturas 186 e 386, a power pc essas máquinas, essa infraestrutura ela vai compilar os pacotes binários para você automaticamente e vai colocar de novo no anstable certo, então primeiro cai no anstable aí depois vai para a testing stable da mesma forma que a gente viu na vez passada e aí tudo isso é copiado para os mihors que quando você usar aqui no final quando você der apt install hello ele vai baixar do servidor mihors, certo para você então motivos, vamos supor você empacou o pacote, você enviou lá para o anstable os pacotes podem ser aceitos pelo time de FTP master ou eles podem ser rejeitados e por que eles podem ser rejeitados eles podem ter erro de licença podem ser que você esqueça o copyright, uma outra coisa também que não é considerada legal é package hijack porque assim, todo pacote ele é associado com o mantenedor, certo não é legal, se você sem avisar para o mantenedor vai lá e envia uma outra versão do pacote isso não é considerado legal você tem que sincronizar com o mantenedor ou o time que responsava para aquele pacote e se o nome do pacote está regular ou se o código fonte não está disponível se acontecer um desses motivos pode ter seu pacote rejeitado e aí como eu comentei os pacotes dentro do anstable migram automaticamente para o testing se acontecer essas coisas aqui então se ele passou pelo menos 10 dias do anstable, desculpa se não tem nenhum bug crítico conhecido se ele compila com sucesso para todas as arquiteturas oficiais do debian e se todas as dependências dele que ele precisa para rodar já estão presente dentro da nossa versão de testing e os pacotes migram de testing para stable são promov... perdão, os pacotes migram de test para stable e a gente tem uma nova versão da versão estável do debian então basicamente a nossa versão de testing é promovida para stable então o stretch atual ele era a versão de testing anterior e isso é feito pelo release manager o cara que gera que coordena todo esse processo fazer uma nova versão acontece cada dois anos e isso acontece de forma gradual então para evitar transtornos o que acontece então você pega o testing a release de testing começa a congelar algumas mudanças então nós primeiros temos um congelamento de transição de bibliotecas vamos supor, você tem um pacote que depende de uma biblioteca programas que dependem de uma biblioteca se você mudar essa biblioteca essa biblioteca muda de de ABI que a gente fala muda lá os headers você tem que recompilar todos os pacotes para linkar de novo com essa biblioteca então primeiro a gente começa a congelar isso para não ter mais essas mudanças depois a gente começa a chamar de um soft freeze um congelamento parcial que não aceitamos mais novos pacotes é e depois que só aceita só aceita nossas versões que corrigem bugs e depois a gente tem um full freeze um congelamento completo onde nós só aceitamos pacotes que resolvem bugs críticos e por exemplo o que aconteceu na última vez quando a gente foi lançar o stretch então em novembro de 2016 nós começamos a congelar novas bibliotecas depois ali em 2017 em janeiro nós não aceitamos mais nossos pacotes e fevereiro nós só aceitamos correções de bug fix e em julho nós tivemos um lançamento oficial do stretch como a nossa versão nova a versão estável então antes da release do stretch a gente tinha lá como a nossa versão estável era o jazz a nossa versão teste era stretch e a nossa versão unstable não estável era o seed e depois dessa release o stretch foi promovido para estável tem um novo nome foi atribuído para a versão de testing e o o unstable sempre continua com o mesmo nome e o interessante é que essas três primeiras datas elas geralmente são acordadas previamente certo mas a data de lançamento final ela não é porque a comunidade tenta corrigir todos os bugs criticos pelo menos antes de lançar a versão estável então todo mundo tenta estabilizar primeiro o sistema antes de lançar a versão estável de lançamento não é muito bem definida e na época se você entrar no site você conseguia ler a seguinte frase lá no site do Deben como sempre a próxima versão do Deben vai ser só lançada quando estiver pronta ou seja, nenhuma previsão de quando vai ser lançada você confia no bom senso das pessoas que vai ser lançada em algum período de tempo nesse caso foi uns quatro meses depois do full freeze certo então quanto tempo a versão estável é suportada quando eu digo suportada é que na versão estável ela é estável novas funcionalidades não entram mais nela o que só entram são correções de bugs e quando a gente fala suportado alguém olhando lá pessoas testando e pessoas aceitando correções de bugs incluindo isso no estável então a versão estável ela tem suporte de mais ou menos três anos e nós temos também um long-term support que dá suporte por mais de dois anos além desses três anos empresas voluntárias que elas não fazem parte da comunidade Deven mas elas mantêm mesmo assim essa versão estável, pois é importante pra elas porque o Deven vai em muito equipamento por aí industrial, certo? então eles têm todo o interesse em manter em corrigir bugs, bug de segurança principalmente em manter essa versão estável atualizada então uma versão estável tem mais ou menos suporte aí de cinco anos ok então os repositórios que nós temos o testem e o não estável nós temos o experimental como eu comentei, o experimental não é uma release, não é uma versão oficial porque você não pode usar só o experimental se você modificar o seu source.list você pode deixar lá só o testem o sol stable, o som uns table pra usar, mas o experimental você não pode porque ele não é completo em si ele é mais usado para as pessoas jogarem lá e pediram alguém pra dar uma olhada, certo? nós temos também um back port que são pacotes do não estável que as pessoas portaram ou do testem, perdão, que as pessoas adaptaram pra que ele funcione bem na versão estável atual então tem uma nova versão do VLC que tem um monte de funcionalidade ele entrou no não estável porque ele não vai entrar no estável já que ele só adicionou funcionalidade não é um bug fix mas alguém que é muito fazê-lo funcionar com a versão estável então alguém vai lá porta ele pra ele funcionar com a versão estável e ao invés de incluir ele no repositório de estável pra adivicar quem está seguindo seu repositório de estável então ele adiciona nesse outro repositório que chama back port um outro repositório chamado updates onde vai os updates o old stable como o nome já diz é a versão estável antiga que é o nosso caso de Jesse e tem várias outras como podemos ver desse grafo meio complicado, certo? então basicamente o que a gente considera em desenvolvimento então repositórios em desenvolvimento ali vocês vão ver o não estável eu não vou passar por todos esses sem dúvidas se quiserem saber detalhes sobre o que é cada repositório eu posso explicar pra vocês depois então ali a gente consegue ver a versão não estável que é parte de desenvolvimento que em vermelho o testing que são os que estão em amarelo e as versões que enxam em produção as versões estáveis que são o verde ali certo? então essas linhas mais ou menos mostram pra você como funciona ok? certo então mantendo um pacote meras mortais como eu e como muita gente que não são nem debian não são membros oficiais do projeto não tem acesso a submeter o pacote diretamente para o debian você faz isso tiramente através de uma outra pessoa certo? então nós temos na verdade dois papéis duas pessoas que podem fazer a submissão um é o debian maintainer que a gente chama de DM um mantenedor de um pacote que ele pode submeter pacotes diretamente para os repositórios do debian nós temos o debian developer que o devor do debian que é o DD que ele realmente é um membro oficial do projeto ele tem direito ao voto e ele pode se candidatar a ser um líder do projeto ele tem acesso a vários servidores do do debian e ele pode propor e votar nos amênomes que eu tinha comentado ou resoluções gerais que é basicamente assim, ah, não estou concordando o que o líder do projeto está fazendo ou quer tomar uma atitude que vem trabalhando então todo mundo faz uma proposta e todo mundo vota e se aquilo passar eles podem sobre-escrever uma decisão do líder do projeto ok? mas se vocês quiserem contribuir enviando pacotes para o debian vocês não precisam ser um mantenedor ou um membro oficial do projeto e para vocês enviarem esses pacotes todo mundo pode submeter um pacote através que a gente chama de sponsor que é simplesmente uma pessoa que tem essa habilidade de mandar para você é um debian maintainer ou um debian developer que te ajuda é por você, lógico vai estar o seu nome lá, o crédito é todo seu mas ele só coloca o seu pacote para dentro se você quer participar, que é quanto começar a contribuir e submeter pacotes você precisa achar um sponsor tem um canal no IRC para quem não sabe quem é IRC é simplesmente um chat basicamente que nós temos e tem um canal de chat que se chama hashtag da Summeters que você pode chegar lá e perguntar olá, tem esse pacote, quero enviar por favor me ajude então basicamente tem essa linha de posições aqui tem os sponsors tem o debian maintainer para você enviar um pacote, você pode começar a enviar um pacote através de um sponsor depois você pode pedir para virar um debian e depois você pode pedir para virar um membro oficial do projeto certo, então vamos falar do sistema de traqueamento de bugs do debian esse sistema pode ser acessado pelo bugs.dem.org e esse sistema que nós temos online, ele que vocês podem ver ele não é só para bugs mas também para requisitar fazer umas requisições, por exemplo se você quiser uma nova funcionalidade no debian você pode colocar lá essa sugestão, se você precisa de ajuda você pode pedir pelo sistema de bugs o sistema de bugs é basicamente você está registrando alguma coisa ele tem o que a gente chama de tickets você pode abrir e escrever alguma coisa que a gente vai inclusive reportar bugs mas também não é só isso e cada bug quando você reporta um bug ele sempre está associado com uma tag ou essa tag pode ser um pacote mas não necessariamente um pacote o que a gente vai ver temos uma interface e-mail para reportar um bug é simplesmente um e-mail num formato específico mas tem uma ferramenta legal chamado report bug que ela simplesmente ajuda você a gerar esse e-mail nesse formato desejado você não precisa lá preencher na mão ele já gera um formato bonitinho para você se você quiser reportar um bug contra o o comando hello você simplesmente executa lá report bug-file e aí você passa o hello ali o legal é que ele já preenche para você informações para enviar para o mantenedor desse pacote hello ele vai preencher para você qual é o sistema que você está usando e essas informações são muito úteis para o cara manter nesse pacote saber que é o bug e essa é a cara de um e-mail então está meio pequeno aí mas basicamente você está enviando e-mail para submits submits-bugs.dm.org aí você fala um assunto o pacote hello o pacote hello na verdade está dizendo adeus não deveria ser assim então você põe ali o pacote a informação do pacote está dando erro a descrição do problema é uma coisa que ajuda bastante é ter um log de erro se você tem mensagem de erros que você possa colocar mais informações é fazer uma sugestão a sugero que no arquivo lá do código fonte vai dizer adeus que diga o lar e fala o que você está usando eu estou usando um debian a versão do debium a versão do kernel de biblioteca que você está usando e diversas informações são úteis lógico, não são necessárias se você já achou um bug reportor muito legal agradeço mas se você conseguir colocar mais informações isso vai facilitar a vida do pessoa que está mantendo esse bug para conseguir resolver esse problema certo então como eu falei quando você coloca um novo ticket nesse sistema não necessariamente você sabe ou faz sentido associar um pacote de um software junto nesse bug report às vezes o bug pode ser um bug geral assim que você não sabe onde encaixar ou ele pode ser um bug nos mirrors ou pode ser um bug naquele sistema que a gente viu ali de aceitar pacotes que não está funcionando direito você submeteu e não chega alguma coisa aconteceu certo você não tem um pacote associado ou você quer pedir para alguém te ajudar você empacotou alguma coisa mas você não é um developer nem um developer maintainer você pode pedir através do sistema um sponsor para te ajudar então essas tags que a gente fala aqui é o que chama de piseu do pacotes que é o que você quando você tem um pacote associado a piseu do pacotes que é o que você quando preenche o formato do e-mail quando você colocar a preencher o pacotes é essa piseu do hotel que você vai preencher e tem um negócio legal que eu vou falar um pouco mais agora que é um piseu do pacote chamado WNPP que é o work needing and prospective package aqui vamos ver o que é isso certo todo pacote há um mantenedor que mantém o pacote ou um time que cuida desse pacote ou está orphan coitado o pacote ninguém está cuidando dele não está sendo atualizado mas ele está resolvendo o bug então vamos supor que você quer ir lá pedir eu quero empacotar esse negócio e é legal você registrar isso no sistema porque vai que outra pessoa tem a mesma ideia que você pode ver e ficar lá no sistema já tem essa pessoa trabalhando nisso vou entrar em contato com ela e a gente vai trabalhar junto certo então você coloca report um bug com essa para esse pacote que é um piseu do pacote da WNPP no assunto do e-mail você coloca umas tags que você vai informar o que você quer fazer então umas tags interessantes é o ITP que é Intensive Package, você vai declarar que tem software legal eu quero empacotar eles esse daí, certo o O, dois pontos, que é Orpho que é cansei, muito trabalho esse negócio, não tenho mais tempo quero abandonar esse pobre coitado do pacote RFA que é o Request for Adoption adotar um pacote Orpho, você é uma pessoa muito legal o pacote lá está Orpho você vai lá adotar ele a diferença do primeiro que é o Intensive Package, eu quero empacotar é que o Intensive Package é para novos pacotes novos programas que nunca foram empacotados e nós também temos o RFH, Request for help então se você tem muito trabalho para fazer você não está dando conta o seu pacote é muito grande ou você pegou vários pacotes e agora, sei lá, o trabalho a faculdade está ocupando muito espaço você não está dando conta do trabalho você quer que alguém te ajude então você vai lá e abre um Request for help e também tem o RFP que é um Request for Package você vai requisitar que um pacote seja empacotado ele é bem parecido com o primeiro a diferença é que você falou eu acho que seria legal esse programa sem pacotado mas eu não quero fazer o trabalho então deixa lá que você se interessa por isso então um exemplo está muito pequeno, não dá para ver mas enfim, esse é um se você não vai dar para ver o porto de um WNPP o pacote está falando WNPP é um RFP um Request for Package que seria legal para acotar o software que é BB Bike que é um planejador de rotas para ciclistas só que a pessoa não quer fazer o trabalho ela só mostra o interesse ao ter no débil então é mais ou menos assim que você interage em relação a pacotes com a comunidade através do sistema de do BTS então como contribuir a gente falou várias coisas no painel que foram muito legais aqui várias coisas já foram cobertas pelo painel então por exemplo você pode ajudar com documentação com tradução você pode ajudar reportando bugs você pode ajudar também enviando e revisando correções que a gente chama de patches então se você achou um bug você pode resolver ele você pode enviar esse patch ou não, ou se outra pessoa que enviou essa correção você pode lá dar uma olhada verificar se está tudo ok e dar um joinha lá de uma olhada verifiquei porque aí o mantenedor já vê não, já tem alguém que olhou não precisa olhar tão afundo agora você pode também ajudar mantendo um pacote pode ajudar também ajudando novatos uma coisa que eu acho que não foi comentada no painel de hoje de manhã é que você pode ajudar com doação isso também ajuda bastante e outra forma é você pode adotar um pacote Orphan você gostaria de pacotar não sabe o que projeta em pacotar tem vários projetos abandonados lá que você pode adotar tem uma lista enorme e tinha vários projetos interessantes um projeto que eu tinha visto que estava antes Orphan era o dia mas o Rodrigo adotou e há pouco tempo o dia é um software de diagrama era ótimo para a faculdade você fazia lá um fluxo grande, bonitinho era bem simples, bem simplistas mas bem eficiente, era bem legal tinha um também acho que era o BitTorrent que estava o que BitTorrent não lembra agora exatamente que estava a Orphan também que eu bati o olho e falei caraca, eu usava isso e ele está a Orphan e vocês podem lá dar uma olhada nessa lista e ver se tem alguma coisa que interessa e adotar esses pacotes ok, Deben versus Ubuntu muita gente pensa que as duas distribuições são concorrentes só que quero desmentificar isso porque o Ubuntu na verdade é outra distribuição mantida pela Canonico que ele é baseado no Deben e o foco dele é um pouco diferente ele suporta apenas alguns algumas arquiteturas nós suportamos oficialmente 9 o Ubuntu suporta apenas, ele está dizendo 3 mas tem uma quarta lá que também é dúvida mas é basicamente a x86 a md64, power pc e tem sdibms 390x o que o Ubuntu faz o Ubuntu, ela paga pessoas o Ubuntu na Canonico, paga pessoas para manter mais ou menos uns 2 mil pacotes o Deben tem 50, mais 50 mil pacotes mas a Canonico ela mantém a army army 64 é suportada pelo Ubuntu não tinha essa formação na página que eu vei muito obrigada por informar parece que a army army 64 também são suportados oficialmente pelo Ubuntu então a Canonico em si, ela tem um número muito menor de desenvolvedores do que o Deben o comunidade do Deben tem aproximadamente 1000 desenvolvedores a Canonico é menor e eles incentivam muito o desenvolvimento do Deben pois quando o Ubuntu lança uma nova versão o que eles fazem, só mantém 2 mil pacotes e o resto dos 48 mil então o que eles fazem é eles basicamente copiam todos os outros pacotes e não estável para o Ubuntu então basicamente eles copiam se você é um desenvolvedor do Deben indiretamente você está contribuindo também para o Ubuntu e enfim tem mais informações sobre essa relação entre Deben e Ubuntu nesses links Ubuntu para Deben developers para desenvolvedores de Deben e Ubuntu para desenvolvedores do Ubuntu é isso só mais uma coisa, antes de pegar perguntas só queria divulgar essa conferência que a gente está fazendo no final do ano chama Linux Developer Conference Brasil que vai acontecer dia 25, 26 de agosto que a ideia dessa conferência é ser um meeting um ponto de encontro internacional entre a comunidade software do Brasil e do mundo para os sistemas core do ecossistema Linux então a gente vai ter temas como embarcados, interesse das coisas televisão, automotivo e a ideia é que a gente incentive mais o Brasil como desenvolvedores de software livre principalmente trabalhando junto com os projetos upstream e não só desenvolvedores assim como o mercado brasileiro a gente quer porque o mundo lá fora nós somos voluntários mas no final do consulto todo mundo tem que trabalhar certo? E uma coisa que muita gente não vê é um mercado que existe por trás de distribuições guinolinos do Deben e de do ecossistema Linux então essa ideia se vocês puderem seria muito legal enfim, perguntas tem microfone para tá bom certo, a pergunta então é sobre segurança se tem alguém que verifica a segurança do pacote se tem alguma equipe específica que vê se tem falha de segurança e faz essas correções sim, nós temos o nome do time é um time que se chama que é o security team não é muito criativo a segurança eles trabalham muito com assim, quando quando uma falha de segurança descoberta você não pode contar para todo mundo certo? porque se não as pessoas vão começar a explorar esse banho, explorar essa falha de segurança então eles trabalham de uma forma mais privativa eles trabalham antes de divulgar que essa falha de segurança existe eles vão tentar fazer a correção então esse time entre eles, eles recebem esses reports desses bugs de vários lugares do mundo tem o time mais famoso acho que é o Google Project Zero que é um time do Google que eles ficam fazendo teste de segurança em vários projetos software livre para esse time que eles vão reportar primeiro e eles primeiro tendo um trabalho então fazem um update do pacote submetem para o o Deben ele vai para um outro repositório que a gente chama Security Updates se for uma falha de segurança dentro do estável tem que entrar tem que corrigir isso dentro do estável e eles entram de uma forma mais privativa não é público e aí quando alguém aprova ele entra dentro do estável e eles publicam a falha de segurança mais perguntas um comentário sobre o LTS que eles não suportam todas as arquiteturas nem todos os pacotes então também é um porém da extensão se você puder fazer o upgrade só para aqueles casos mesmo que não tem por algum razão não é possível fazer upgrade por causa disso você pode estar na arquitetura e não ter o pacote coberto entendi muito obrigada pela informação a gente viu que os novos pacotes vêm muito pelos desenvolvedores eles propõem novos pacotes, melhorias etc e como é o processo quando funciona quem está na direção do projeto quer que algo seja feito quando vem de cima alguma direção que se deseja dar para o Deben é muito difícil essa posição de vir alguma coisa de cima que o negócio é muito, a gente chama de doocracia, que é fazer doocracia quem faz tem um crédito então o mantenhador tem autoridade tomar decisões no pacote dele porque é ele que está fazendo esse trabalho o líder do projeto os trabalhos que ele faz ele tenta coordenar tudo ele tenta ver onde tem problemas tenta mediar tenta tenta, ele aprova dinheiro para por exemplo, eu fui a funcionalidade do Deben a gente está há mais de dois anos discutindo tentando fazer funcionar, certo? e aí o que a gente resolveu fazer é uma reunião em pessoa para a gente caracara sentar a todo mundo que não estava concordando para tentar resolver os problemas então aí o que esse coordenamento financeiro então a gente pede para ele, você pode pagar para as pessoas certas irem viajar para a gente resolver esse problema, ele vai lá e aprova é muito difícil uma decisão técnica vir de cima o que ele pode fazer é incentivar áreas mas ele não é porque todo mundo é voluntário você não pode obrigar ninguém a fazer alguma coisa não sei se eu passei se alguém tiver uma explicação melhor o trabalho do LTS como você mencionou tem algumas empresas tem alguns envolvedores são pagos para fazer mas faz parte de alguma maneira da duocracia assim como muitos de nós trabalhamos para alguma empresa e nesse trabalho acabamos por contribuir para o Deben mas houve um caso há uns dez anos atrás eu diria em que o DPL tentou voltar para pagar os release managers a comunidade os desenvolvedores optaram por não topar fazer isso no entanto ele foi lá e fez de forma extraoficial e causou todo com dinheiro da comunidade? não ainda assim causou um certo atrito vários membros da comunidade é um exemplo do que que aconteceu de ver a história do que aconteceu naquele momento e hoje a gente tem o LTS que faz um trabalho extraoficial e que ninguém pediu permissão naquele caso ele pediu permissão houve uma votação foi contra ele fez mesmo assim e aí causou um problema tem um pouco daquela história peça desculpas e não permissão que é um pouco dessa atitude mas se você fizer alguma coisa errada e você pede desculpas se você ficar pedindo permissão você nunca vai conseguir alguém que te permita fazer alguma coisa porque não tem quem dê a permissão como você falou em alguns casos não é o cara que dito que vai ser feito também não é ele que autoriza ele não tem autoridade para dizer se você pode ou não fazer um caso legal de se estudar respondeu mais ou menos eu já pego você falou que tem mil desenvolvedores pelo mundo oficiais o cenário no brasil de quantos desenvolvedores tem no brasil o que elas estão atuando os brasileiros acho que foi comentado de manhã que tem mais ou menos 18 desenvolvedores debium oficiais que fazem parte do projeto que não são oficiais eu não sei te dar uma estimativa que de pessoas contribuem mas eu acho que a gente tem uma comunidade bem grande no brasil que contribuem não são debium developers oficiais que não fazem parte daqueles mil mas se eu não me engano foi falado de manhã que tinha mais ou menos 18 brasileiros 5 estavam fora do brasil alguma coisa assim mas eu não sei dizer na verdade bom gente muito obrigada gostou o tempo aqui espero que tenha sido útil para algum de vocês desculpem se estar em inglês muito técnico mas muito obrigada