Pouco mais de um ano atrás, eu publiquei uma série de posts sobre o ciclo de lançamentos da Debian, ao que se seguiu um exercício sobre como um pequeno script python poderia ser usado para acompanhar o número de bugs relacionados a ele.
Aquele exercício tinha vários objetivos, mas o propósito principal dele era ensinar a mim mesmo sobre Python, APIs, JSON e assim por diante. No final daquele exercício eu tinha um pequeno bot hospedado em um serviço online mantendo um registro do número de bugs RC na Testing. Como eu expliquei em um daqueles posts, o Time de Lançamento (Release Team) usa o número de bugs RC como um dos critérios para planejar o lançamento da Stable. Não é uma medida objetiva, e em algum momento eles tomam uma decisão e “dão um jeito” em quaisquer bugs que estiverem sobrando. Por exemplo, esse tweet é da véspera do lançamento:
64 packages with RC bugs in Testing as of today. 0 days until the planned date for Buster’s release. Plan your party! pic.twitter.com/TWumGMRRr7
— Debian Tracker (@debian_tracker) July 5, 2019
Eles tomam a decisão baseando-se em quais são exatamente os bugs que ainda estão abertos. Os pacotes relacionados a eles podem seguir dois caminhos. O Time de Lançamento pode decidir colocá-los no lançamento apesar dos bugs (se o bug não for “tão ruim assim”) ou eles podem resolver remover o pacote, o que significa que esse programa em particular não fará parte da Stable.
E foi isso. A Buster tinha sido lançada, e eu não vi nenhuma utilidade imediata em manter as postagens no Twitter. Eu mantive o bot rodando mas não postei nada; em vez disso, só “retuitei” algumas coisas mais ou menos relacionadas de vez em quando.
Não existe plano à prova de futuro
Na época eu não tinha nenhum plano de médio/longo prazo para outros lançamentos, mas lá no fundo eu sabia que poderia voltar a usar esse bot quandoi fosse a hora. Então, há uns dois meses, quando o primeiro aniversário da Buster estava chegando, eu resolvi voltar ao trabalho com ele. Fiz uma revisão rápida no código, troquei umas datas onde precisava e atualizei os nomes dos lançamentos. E aí o Debian Tracker voltou:
Yesterday was Buster’s 1 year anniversary. The freeze is supposed to start early next year (https://t.co/2EJmFI2FaE), so we’re gonna resume tracking the count of RC bugs, starting today. We’ll be looking into ways of improving tracking and reporting.
— Debian Tracker (@debian_tracker) July 10, 2020
A primeira coisa a fazer, claro, era limpar tudo. Esse bot (por enquanto) não usa nada sofisticado pra guardar os dados, então foi apenas uma questão de limpar os arquivos de texto que continham os dados de antes. Então, eu remarquei a tarefa no PythonAnywhere e ele voltou ao serviço em 10 de Julho.
Novo são significa melhor, mas deveria
Agora que o bot estava de volta à ativa, eu podia pensar em maneiras de melhorá-lo. O primeiro passo, claro, seria reativar o código que gera o gráfico com o número de bugs com o tempo. Isso precisou de uma certa espera, porque um gráfico só com uns poucos pontos ficaria horrível. O primeiro tweet com um gráfico saiu em 3 de Agosto:
Aquele aumento gigante no número de bugs RC é algo para o qual eu ainda não encontrei resposta ainda; ele mais que dobrou de um dia para o outro! Primeiro eu imaginei se teria algo a ver com o fim da vida do Python 2, mas é muito pacote para ser uma coisa só. Uma possibilidade melhor é a mudança para o gcc 10 como compilador padrão; eu vi isso causar muitos erros nos sistemas de geração de pacotes da Debian (algo a que eu pretendo voltar em um post futuro).
Eu também troquei o estilo de linha do gráfico; um simples ajuste de curva não é mais possível porque a curva está bem mais complicada. Conforme o lançamento for ficando mais próximo (provavelmente depois que o Freeze começar) talvez ela fique previsível o suficiente pra isso ser viável novamente.
Eu tenho um problema com esse gráfico, no entanto: ele foi gerado por código antigo. Eu aprendi bastante sobre Python desde quando eu o escrevi, e queria atualizar algumas coisas. Então, foi isso que eu fiz.
Um bug em particular que me deu bastante trabalho foi que o gráfico estava sempre um dia atrás dos dados reais; eu percebi isso no meio de Julho, graças àquele aumento enorme. Levei um tempo para descobrir que eu não estava atualizando os arrays de dados; embora eu estivesse pegando os dados do UDD e salvando nos arquivos de texto, eu não atualizava as variáveis usadas para fazer o gráfico.
“Corte uma cabeça, e duas mais tomam o seu lugar”
Consertar esse bug em particular me levou “para o buraco”, porque tudo começou a quebrar a partir daí; consertar esse bug envolveu dividir algumas funções, daí as variáveis não apareciam mais da mesma forma porque escopos haviam mudado.
Eventualmente eu vou converter a coisa toda para um paradigma orientado a objetos. Isso é algo que eu vou trabalhar em um branch separado. Não quero bagunçar algo que já está funcionando. Além disso, vai levar um tempo até fazer isso, afinal eu não sou exatamente muito experiente em OOP. Mas, de novo, este é um exercício de aprendizado acima de tudo.
Outra melhora no código foi o fato de agora ele fazer distinção entre as severidades dos bugs. em vez de uma única linha com o número total, ele mostra três linhas, com os números de bugs serious, grave e critical. Eu percebi que o número de bugs não é assim tão importante, e ele já está no texto do tweet. Além disso, este formato contém mais informação, então o saldo é positivo.
Trabalho de Zenon
Isto ainda não acabou (e dá pra acabar?). Uma coisa que eu percebi quando olhei para o gráfico gerado pelo bot no final de 2019 é que o eixo X ficou uma bagunça. O código que gera os rótulos é horrível e não funciona bem se os dados cobrem um intervalo de tempo grande. Isso é algo que precisa ser consertado antes que se torne um problema. É o próximo item da lista.
Acima está o gráfico mais recente, publicado no Twitter no dia que estou escrevendo este post. Por agora, estou satisfeito com a aparência dele, mas qualquer sugestão é bem-vinda.
Por enquanto, é isto. Eu queria mostrar código aqui, mas no fim não pareceu necessário. Se você estiver interessado, o código está no gitlab. Sinta-se à vontade para dar uma olhada, já que ele está sob a licença MIT (a mesma do twitterbot_framework, no qual eu me baseei). Você pode olhar o repositório aqui.
Deixe um comentário