Published by Jon on April 24th, 2015 in Debian | 2 Comments »
Release day is a nerve-wracking time for several teams. Happily we’ve done it a few times now*, so we have a rough idea of how the process should go.
There have been some preparations going on in advance:
- Last week we imposed a “quiet period” on migrations. That’s about as frozen as we can get; it means that even RC bugs need to be exceptional if they aren’t to be deferred to the first point release. Only late-breaking documentation (like the install guide) was accepted.
- The security team opened jessie-updates for business, carried out a test upload, and have since released several packages so that those updates are available immediately after release.
- The debian-installer team made a final release.
- Final debtags data was updated.
- Yesterday the testing migration script britney and other automatic maintenance scripts that the release team run were disabled for the duration.
- We made final preparations of things that can be done in advance, such as drafting the publicity announcements. These have to be done in advance so translators get chance to do their work overnight (the announcement was signed off at 15:30UTC today, translations are starting to arrive right now!).
The following checklist makes the release actually happen:
- Once dinstall is completed at 07:52, archive maintenance is suspended – the FTP masters will do manual work for now.
- Very large quantities of coffee will be prepared all across Europe.
- Release managers carry out consistency checks of the Jessie index files, and confirm to FTP masters that there are no last-minute changes to be made. RMs get a break to make more coffee.
- While they’re away FTP masters begin the process of relabelling Wheezy as oldstable and Jessie as stable. If an installer needs to be, er, installed as well, that happens at this point. Old builds of the installer are removed.
- A new suite for Stretch (Debian 9) is initialised and populated, and labelled testing.
- Release managers check that the newly-generated suite index files look correct and consistent with the checks made earlier in the day. Everything is signed off – both in logistical and cryptographic terms.
- FTP masters trigger a push of all the changes to the CD-building mirror so that production of images can begin. As each image is completed, several volunteers download and test it in as many ways as they can dream up (booting and choosing different paths through the installer to check integrity).
- Finally a full mirror push is triggered by FTP masters, and the finished CD images are published.
- Announcements are sent by the publicity team to various places, and by the release team to the developers at large.
- Archive maintenance scripts are re-enabled.
- The release team take a break for a couple of weeks before getting back into the next cycle.
During the day much of the coordination happens in the #debian-release, #debian-ftp and #debian-cd IRC channels. You’re welcome to follow along if you’re interested in the process, although we ask that you are read-only while people are still concentrating (during the Squeeze release, a steady stream of people turned up to say “congratulations!” at the most critical junctures; it’s not particularly helpful while the process is still going on). The publicity team will be tweeting and denting progress as it happens, so that makes a good overview too.
If everything goes to plan, enjoy the parties!
(Disclaimer: inaccuracies are possible since so many people are involved and there’s a lot to happen in each step; all errors and omissions are entirely mine.)
* yes yes, I am being particularly English today.
Published by Jon on April 24th, 2015 in Debian |
One further contributor became a non-uploading Debian Developer in 2015, joining 11 others who achieved that status its introduction in 2010.
Non-uploading developers are really important to our project. They’re a recognition of the invaluable work that contributors do which doesn’t involve packaging, for which they may not have the skill nor inclination. Nevertheless we would be much weaker without those tireless contributions in the community, translations, bug handling – the list is much longer and covers every aspect of Debian life.
If you’re reading this and thinking “I have a sustained involvement in some aspect of Debian, and make regular contributions”, please consider chatting to those you work with and see if you’re ready to be recognised too.
Published by Jon on April 23rd, 2015 in Debian |
Two years, give or take a few weeks, is roughly the time required to prepare a new stable release since Sarge in 2005 (source: http://en.wikipedia.org/wiki/Debian#Release_timeline). A Spring release has also been a pretty stable pattern during that time.
Debian often has a reputation for being very slow to release (in terms of cadence), or for freezes to hold up development for an excessive length of time, but the current pattern does lend itself well to two attributes: predictability and reliability (in terms of high-quality releases). It’s true that this means shipping with slightly older versions of major software, but you can sleep well knowing they’re thoroughly tested – and that’s really important in Debian’s core market, which tends to be highly-available services rather than desktop machines.
There’s always backports.
Published by Jon on April 22nd, 2015 in Debian |
Three is the new number for continuing oldstable security support: thanks to the efforts of those behind the Long-Term Support initiative, the full stable lifecycle of a release has therefore become five years (source: https://www.debian.org/News/2014/20140424).
Where do those numbers come from? 2 years as stable, 1 year overlap support as oldstable, plus 2 new years under LTS = 5 years.
Having been successful for Squeeze (6), LTS is widely anticipated to follow a similar pattern for Wheezy (7) and Jessie (8) for the same lifetimes. Some reduction in coverage is unavoidable (for example, Squeeze only covers the most popular amd64 and i386 architectures), but for a majority of users this reduces the need to follow a three-year upgrade cycle – invaluable when you are managing hundreds or thousands of servers and can’t achieve that in a single year.
Published by Jon on April 21st, 2015 in Debian |
For some reason, I’ve decided that gallivanting around the London Underground for the day one Saturday is a fine way to raise money for a local children’s hospice. You’d make my day by supporting us – we aren’t deducting expenses from pledges, so there’s no penalty to the charity for our travel.
We’re going to run a modified version of the Guinness-recognised Tube Challenge starting about 05:15 (modified to allow for unavoidable maintenance works; we don’t have the luxury of being able to pick a day when that’s not going to be a problem) and likely finishing about midnight.
I’m also interested to hear ideas for some kind of micro-blogging platform that we can update on the move, preferably presenting in stream format and with an Android-friendly site/app that can cope with uploading a photo smoothly. Not Twitter or Facebook; it’ll probably be a short-lived account. I don’t want to part with personal information and I want to be able to throw it away afterwards. Suggestions?
Published by Jon on April 21st, 2015 in Debian |
Four architectures – types of computing device that you can use to run Debian – didn’t make it through architecture qualification for Jessie and won’t be part of the official stable release this weekend.
It’s always difficult to see architectures go, particularly when there is still a community interested in maintaining support for them. Nevertheless, sometimes a port just doesn’t have enough momentum behind it or sufficient upstream interest from the toolchain to be economical. Whether a port is of sufficient quality for stable is a complex decision involving several different teams – Debian System Administration, the security team, those who maintain the auto-builder network, the release team, and so on – and will continue to affect them for several years.
It’s not all gloom though: new architectures in Jessie include arm64, ppc64el (a 64-bit version of powerpc) and s390x (replacing Wheezy’s s390). Architecture rotation can be healthy.
(source: https://release.debian.org/jessie/arch_qualify.html. ia64 and s390 were planned retirements following Wheezy, leaving hurd-i386, kfreebsd-i386, kfreebsd-amd64 and sparc which didn’t satisfy all qualification criteria by the time decisions had to be taken.)
Published by Jon on April 20th, 2015 in Debian |
Five contributors became uploading Debian Developers so far in 2015 (source: https://nm.debian.org/public/people).
Published by Jon on February 8th, 2015 in Debian |
I like how contributors.debian.org reminds me of things I used to have time for, and motivates me to find some for them.
Published by Jon on January 20th, 2015 in Debian |
With over a hundred RC bugs still outstanding for Jessie, there’s never been a better time to host a bug-squashing party in your local area. Here’s how I do it.
- At home is fine, if you don’t mind guests. You don’t need to seek out a sponsor and borrow or hire office space. If there isn’t room for couch-surfers, the project can help towards travel and accommodation expenses. My address isn’t secret, but I still don’t announce it – it’s fine to share it only with the attendees once you know who they are.
- You need a good work area. There should be room for people to sit and work comfortably – a dining room table and chairs is ideal. It should be quiet and free from distractions. A local mirror is handy, but a good internet connection is essential.
- Hungry hackers eat lots of snacks. This past weekend saw five of us get through 15 litres of soft drinks, two loaves of bread, half a kilo of cheese, two litres of soup, 22 bags of crisps, 12 jam tarts, two pints of milk, two packs of chocolate cake bars, and a large bag of biscuits (and we went out for breakfast and supper). Make sure there is plenty available before your attendees arrive, along with a good supply of tea and coffee.
- Have a work plan. Pick a shortlist of RC bugs to suit attendees’ strengths, or work on a particular packaging group’s bugs, or have a theme, or something. Make sure there’s a common purpose and you don’t just end up being a bunch of people round a table.
- Be an exemplary host. As the host you’re allowed to squash fewer bugs and instead make sure your guests are comfortable, know where the bathroom is, aren’t going hungry, etc. It’s an acceptable trade-off. (The reverse is true: if you’re attending, be an exemplary guest – and don’t spend the party reading news sites.)
Now, go host a BSP of your own, and let’s release!
Published by Jon on January 18th, 2015 in Debian |
We have had a rather more successful weekend then I feared, as you can see from our log on the wiki page. Steve reproduced and wrote patches for several installer/bootloader bugs, and Neil and I spent significant time in a maze of twist zope packages (we have managed to provide more diagnostics on the bug, even if we couldn’t resolve it). Ben and Adam have ploughed through a mixture of bugs and maintenance work.
I wrongly assumed we would only be able to touch a handful of bugs, since they are now mostly quite difficult, so it was rather pleasant to recap our progress this evening and see that it’s not all bad after all.