No meu último post eu descrevi como funciona o ciclo de lançamentos da Debian. De fato, o melhor que podemos esperar é uma data de lançamento planejada, mas mesmo isso depende de como as coisas avançam durante os estágios finais do congelamento, e mesmo assim uma data planejada de lançamento só é decidida bem perto do final desse processo.
Prever com precisão quando uma nova versão do Debian vai sair é, portanto, uma tarefa bem difícil. Neste post eu vou cobrir como podemos, pelo menos, ter alguma idéia de quão avançado ele está – e o que eu fiz a respeito.
Bugs RC
Um dos conceitos principais a vida da Testing é o número de bugs que ela tem. De particular interesse são os bugs considerados “Críticos ao Lançamento”. Esses bugs são especialmente sérios, o que significa que eles afetam o lançamento diretamente. Ou seja, ele não pode acontecer enquanto esses bugs permanecerem. Nenhum pacote no lançamento pode ter um bug RC não resolvido.
Bugs RC são quaisquer bugs que se encaixem em um dos seguintes níveis de severidade:
- Serious: o bug é uma violação da política Debian, ou, na opinião do mantenedor do pacote ou do gerente de lançamento, inviabiliza o pacote para o lançamento
- Grave: o bug deixa o pacote inutilizável, causa perda de dados ou introduz um risco de segurança no nível de usuário
- Critical: cria várias dificuldades, causa falhas em outros programas não relacionados (ou no próprio sistema), causa perda séria de dados ou introduz um risco de segurança para todo o sistema
Então é razoável se esperar que, uma vez que todos os bugs RC estejam resolvidos, o resultado é um sistema operacional que funciona muito bem, se não perfeitamente; pelo menos, não haverá nenhum “deal-breaker“.
“Marca na agenda”
Embora seja de se esperar que o número de bugs RC chegue a zero antes de planejar um lançamento, na prática isso não acontece; afinal, o tempo é limitado e só é possível esperar um certo tempo antes de atualizar. Então, quando o número de bugs RC fica pequeno o suficiente, e dependendo dos bugs que ainda restam, a Equipe de Lançamento da Debian toma a decisão. Quaisquer pacotes que ainda tenham bugs RC são marcados com “defer” ou com “remove“.
Um pacote marcado com buster-can-defer tem seus bugs “adiados”: isso significa que esse bug, embora seja sério o suficiente para ser classificado como Crítico ao Lançamento, pode ser contornado de uma forma ou de outra e pode ser consertado depois, seja em um lançamento pontual (atualizações cumulativas que aumentam a versão menor – 9.1, 9.2, etc) ou na próxima stable.
Um pacote marcado com buster-will-remove, no entanto, pode causar muitos problemas, mas por uma razão qualquer ainda não foi corrigido. Existem várias razões para isso. Talvez o bug seja muito sério e precise de muito trabalho. Talvez o upstream ainda esteja trabalhando nele, ou talvez eles não se importam. De qualquer forma, esse pacote é removido do lançamento; nesse caso, é melhor lançar sem esse programa do que simplesmente não lançar. Esse pacote pode voltar se o bug acabar sendo corrigido.
Dois minutos para… lançar?
Por exemplo, para a Stretch esse limiar foi cruzado em 04 de Junho de 2017, com este email de Niels Thykier para a lista debian-devel-announce:
All RC bugs have been tagged with either “stretch-can-defer” or “stretch-will-remove”. If a package has an RC bug tagged “stretch-will-remove”, then it will be manually removed from stretch next week (unless it is fixed and the fix migrates to stretch before the deadline on Friday, 2017-07-09) […]
Niels Thykier, “Final boarding call for the stretch release” – June 04, 2017
Com a data final marcada, o relógio começa a contar o tempo para as mudanças de última hora. Mantendo em mente que qualquer mudança tem que ficar um par de dias na unstable antes de entrar na testing. O protocolo é extremamente importante, especialmente a essa altura, e toda e qualquer mudança é revista e aprovada manualmente.
Com o passar da data final, mais uma semana é dada para os ajustes finais e o ocasional patch de emergência, e o lançamento acontece.
Quantos bugs faltam?
A Equipe de Lançamento toma sua decisão baseado em quantos bugs RC ainda restam, assim como na natureza de cada bug. É dificil avaliar objetivamente esses bugs baseado no que cada um significa, mas podemos pelo menos manter um registro do número deles.
Para isso, a primeira página que é possível checar é o Gerenciamento de Lançamento Debian. Esse site mantém um registrop de tudo relacionado ao lançamento, stable ou testing. A Equipe de Lançamento usa essa página para publicar notícias sobre os esforços deles, então é uma boa página para acompanhar.
Ela tem detalhes sobre o processo de lançamento, atualizações da stable, listas de pacotes a serem removidos, quais os critérios de migração, e assim por diante. Tem muita informação ali.
Outra página cheia de informações sobre o lançamento é, naturalmente, o sistema de rastreio de bugs. Principalmente a seção dedicada aos bugs RC. É ali que conseguimos nosso primeiro número relacionado ao progresso da testing rumo ao lançamento: o número de bugs RC relationados ao próximo lançamento. A página inclui até mesmo um gráfico que mostra o númeo de bugs ao longo do tempo nos últimos dois anos, e um link para um gráfico com todos os bugs desde 2003.
A Fonte Suprema de Dados
Para informações ainda mais detalhadas, também é possível usar o Ultimate Debian Database. Qualquer um com disposição para explorar um pouco pode usar esse site para ter acesso a uma parcela bem grande da base de dados SQL da Debian. Ela pode ser usada para conseguir informações sobre mantenedores e equipes trabalhando nos pacotes e informações sobre os pacotes em si, além de informações sobre os bugs (é claro).
Usando essas páginas, podemos saber quantos bugs RC ainda restam. Quando esse número fica “baixo o suficiente”, todo o processo de “defer/remove” começa, e o lançamento é iminente. Mas checá-las não é muito prático, no entanto, a menos que se esteja procurando por informações mais detalhadas. Para se ter uma idéia rápida de quantos bugs faltam, algo mais curto e mais acessível é preferível.
Python ao resgate
É aí que entra o Python. Selecionando algumas opções no UDD podemos conseguir uma sentença SQL que liste todos os bugs RC que afetam a testing. É basicamente a mesma coisa que usar a seção da testing do BTS. A diferença é que o UDD pode nos dar toda essa informação em um conveniente arquivo JSON.
Usando a biblioteca JSON do Python, podemos fazer isso de dentro de um script:
import json
def num_bugs():
URL = "https://udd.debian.org/bugs/?release=buster&fnewerval=7&flastmodval=7&rc=1&sortby=id&sorto=desc&format=json#results"
data = requests.get(URL).json()
return len(data)
Claro, o objeto data contém bem mais informação que estamos usando; e se quiséssemos poderíamos fazer coisas mais interessantes com isso. Mas no momento só queremos mesmo o número de bugs, então len(data) será suficiente para os nossos objetivos. Ele já contém o que nos interessa, que é o número de bugs RC na testing.
Mas podemos ir além; usando a biblioteca tweepy, podemos compor um tweet e submetê-lo usando a API do Twitter. Tem, é claro, o detalhe de abrir uma conta e a chave de API para fazer isso. Mas, uma vez que isso seja feito, é só compor o texto e enviar (com uma ajudinha da datetime):
import tweepy
import datetime
def compose_tweet(n_bugs):
freeze = datetime.datetime(2019,1,12)
today = datetime.datetime.now()
t_days = today-freeze
tweet = str(num_bugs) + "packages with RC bugs in Testing as of today (" + t_days + day_th + " day of the freeze)"
if __name__ == "__main__":
tweet_text = compose_tweet(num_bugs())
A função compose_tweet(n_bugs) recebe um argumento, que é o número que conseguimos da nossa função de antes, num_bugs(). Então, se tivermos chamado o script pelo nome, ele compõe o texto e envia. Voilà! Um feed to Twitter fácil de seguir, que nos dá uma medida do ótimo trabalho da Equipe de Lançamento em direção a mais uma Debian Stable.
Comentários Finais
Como no post anterior, este também contém um pouco de adivinhação; mas é basicamente continuação do que escrevi antes. A maior parte do que está aqui veio de um pouco de exploração nos arquivos de listas de discussão, e até mesmo uma troca rápida de idéias com o Niels Thykier no IRC.
Os pedaços de código python que mostrei aqui são parte do bot que eu escrevi para fazer exatamente o que eu descrevi. Ele busca no UDD diariamente e posta o resultado no Twitter, alternando entre o número de dias desde o início do freeze e quanto tempo faz desde o lançamento da Stretch. No começo eu rodava ele como um cron job na minha máquina Buster no trabalho, no entanto a energia pode falhar e eu queria algo mais confiiável, então agora ele está hospedado no pythonanywhere.com (que não patrocinou este post, aliás).
Eu vou continuar rodando esse bot até o lançamento. Depois disso, não tenho certeza. O freeze da Bullseye ainda não é nem um sonho de ninguém, mas eu acho que poderia seguir alguma outra estatística relevante.
Deixe um comentário