In my last post I went over how Debian’s release cycle works. In fact, all we can hope for is a planned release date, but even that depends on how things progress during the final stages of the Freeze, and even then a planned release day is only settled on very late in the process.
Accurately predicting when a new version of Debian is going to come out is, therefore, not an easy task. In this post I will go over how we can have at least some idea of how far along the process is – and what I did about it.
RC Bugs
One of the main concepts in the life of Testing is how many bugs it has. Of particular concern are those bugs that are considered “Release Critical”. These bugs are particularly serious, which means they affect the release directly. In other words, the release cannot happen while they remain open. No package in the release is allowed to have an unresolved RC bug.
Release Critical bugs are any bugs that have any of the following severity levels:
- Serious: the bug is a violation of Debian policy, or in the opinion of the package maintainer or release manager, makes the package unsuitable for release
- Grave: the bug renders the package unusable, causes data loss, or introduces some security risk at the user level
- Critical: creates several difficulties, causing other software on the system to break, causes serious data loss, or introduces a security risk to the whole system
Therefore, it’s reasonable to expect that, when all RC are sorted out, the result is an operating system that works very well, if not perfectly; at least, there are no “deal-breakers”.
“Save the date”
Although one would expect the number of RC bugs to become zero before actually planning a release, in practice this does not happen; after all, time is limited and one can expect to wait only so much before upgrading. So, when the number of RC bugs becomes “low enough” the Debian Release Team makes the call. Whatever packages that still have bugs are marked with “defer” or with “remove”.
A package that gets marked with buster-can-defer has its bugs “postponed”: this means that this bug, although serious enough to be classified as Release-Critical, can be dealt with one way or another, and it can be fixed later on, either in a point release (cumulative updates that move up the release’s minor version – 9.1, 9.2, etc) or in the next stable.
A package that gets marked with buster-will-remove, however, could cause a lot of trouble, but for some reason or another, it has not yet received a fix. There are a lot of reasons for that. Maybe the bug is too serious, and requires too much work. Maybe the upstream is still working on it or maybe they don’t care that much. In any case, that package gets removed from the release; in this case, it’s better to release without that particular program, than to release nothing at all. That package can make it back in, if and when that bug gets fixed.
Two minutes to… release?
For example, for Stretch that threshold was crossed on June 04, 2017, with Niels Thykier’s email to 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
With the deadline set, the clock begins to tick for those final, last-minute changes. Keep in mind that any change has to spend a couple of days in unstable before entering testing. Protocol is extremely important at this point, and every change is manually reviewed and approved.
After the deadline, there is a last week for some fine tuning and the occasional emergency patch, and the release happens.
How many bugs are left?
The Release Team makes their decision based on how many RC bugs are left. The nature of those bugs is taken into account as well. It’s difficult to objectively judge them on quality, but we can at least track their numbers.
To do that, the first page one can check is Debian’s Release Management page. This site tracks all kinds of things related to release, be it stable or testing. The Release Team uses this page to publish news about their efforts, so it’s a good one to track.
It has details about the release process, planned point releases for stable, lists of packages that might get removed, what are the criteria for package migration, and so on. There is a lot of information there.
Another page that is full of release-related information is, naturally, the bug tracker system. Especially the section dedicated to RC Bugs. That’s where we get our first number related to the progress of testing towards release: the number of bugs concerning the next release. The page even includes a graph showing the number of bugs over the last two years. There is also a link to a graph with data going back all the way back to 2003.
The Ultimate Source of Data
For even more detailed information, one can also use the Ultimate Debian Database. Anyone willing can use it to have access to a large cross-section of the Debian SQL database. You can use it to access a lot of information about Debian packages. That includes maintainers and teams taking care of each package, as well as information on bugs (obviously).
Using these pages, we can know how many RC bugs are left. When that number gets “low enough”, the whole “defer/remove” process begins, and the release becomes imminent. Checking it, however, is not very practical, unless you are looking for detailed information. For a quick idea on how many RC bugs are left, something shorter and more accessible is desirable.
Python to the rescue
That’s where python comes in. Selecting a few options in UDD we get a SQL sentence that lists all the RC bugs affecting the testing release. That is basically the same thing we can get using the bug section of the BTS. The difference is that UDD can give us all of this data in a convenient JSON file.
Using Python’s JSON library, we can have access to it from inside a 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)
Granted, the data object contains much more information than we are using; and we could find other interesting ways to use that if we wanted to. But, for now, len(data) is quite enough for our purpose, and it already contains the information we really want – the number of RC bugs in testing.
We can do more than that; using the tweepy library we can compose a tweet and submit it using Twitter’s API. There is of course the small matter of setting up an account and the API key for it to work. But, once that’s done, we can compose a tweet and submit it (with a little help from 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())
The compose_tweet(n_bugs) function receives one argument, which is the number we get from our previous function (num_bugs()). Then, if we called our script by name, it composes a tweet and sends it. Voilà! One easy to track twitter feed that gives us a measure of the progress of the Release Team’s amazing effort in bringing us another Debian Stable.
Final Remarks
As in my previous post, this one also contains a bit of guesswork; but it’s mostly a follow-up to what I wrote before. Most of what I wrote here came from a lot of digging around in mailing lists archives, and even a quick exchange with Niels Thykier himself in IRC.
The python snippets I showed here are part of the bot I wrote to do exactly what I described. It queries UDD daily and posts the result to twitter. It alternates between the number of days since the freeze began and how long it has been since the release of Stretch. In the beginning I was running it as a cron job from my Buster box at work. But power may go out sometimes and I wanted something more reliable. For that reason it’s hosted on pythonanywhere.com (which did not sponsor this post by the way).
It’s going to be running everyday until Buster releases. After that, I’m not sure yet. The freeze for Bullseye is not even a gleam in anyone’s eyes, but I suppose I could set it to track some other kind of relevant information.
Leave a Reply