Bug #16600
release_process: please clarify versions
0%
Description
If there should be a single issue I faced during the 3.13 release process, this is the one.
There are a fair number of assumptions in release_process.mdwn, including the rhythm of major and bugfix releases. At least: one is expected to know about the next major release, and about the one after that! Which isn’t the case right now, as we have a number of bugfix releases in a row, followed by a major release which has an unknown version number (3.17 or 4.0). Admittedly, this could be called a corner case, but it’s bound to be repeated for at least 3.14, and maybe 3.15, depending how far ahead scheduling (major) releases is going to happen.
I’ve tried to adapt as best as I could the instructions so they would make sense, targetting the next two releases (3.14 and 3.15, both bugfix); I’ve also opened Bug #16572 and asked another RM to look at it urgently (again, thanks for the swift answer) to make sure what I was doing wasn’t entirely crazy. I didn’t read all the reply (Bug #16572#note-1) and stopped at “tl;dr: for 3.13, go for what you did already; for next time, read what follows.” and a similar “it’s fine, carry on” on XMPP.
But the next day, I tried to follow the post-release steps (which for various organisational reasons I managed to dodge most times until now…) to put 3.17 as the next major version in the devel branch, which I’m told would break the test suite.
I find it very hard to:
- decide what should be set through various environment variables. This has gotten better with the great MAJOR vs. BUGFIX renaming/clarification rounds though. But that started with some kind of cargo-culting, copying and pasting the RM’s file for the previous release, and trying to guess what should be bumped.
- understand all the implications of specifying this or that version at a given step. While this might be OK if one were able to follow the release process documentation blindly, experience for all RMing iterations I’ve taken part in shows that there are always exceptions and deviations that one should be prepared to operate.
Therefore, I would very much welcome some kind of “definitive guide to versions” that would help RMs remember everything there is to know about versions/branches/etc.; or at the very least, help RMs operate consistent choices when they have to deviate from the release process documentation.
Again, looking at previous release cycles, there are always many things to prepare on release day 1, the release itself to publish on day 2 (usually waiting on the MFSAs, so we cannot expect to finish everything on that day, even for a night owl like me), and post-release steps. Given how busy days 1 and 2 are, even with more experience, I don’t think I’ll ever manage to get post-release steps done before day 3. And keeping a train of thoughts over 3 days doesn’t seem realistic, at least to me (e.g. if I had read and understood the last part of Bug #16572#note-1 on day 1, I wouldn’t have thought about it and anticipated all the consequences, when performing post-release steps on day 3).
Subtasks
History
#1 Updated by intrigeri 2019-03-22 19:29:01
- Assignee set to intrigeri
- Target version set to Tails_3.14
#2 Updated by intrigeri 2019-03-23 13:22:01
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|d30a11a9253e61de8270e3996c4dcf4ab2e1f507.
#3 Updated by intrigeri 2019-03-23 13:24:25
- Assignee changed from intrigeri to CyrilBrulebois
- QA Check set to Ready for QA
- Feature Branch set to master
> There are a fair number of assumptions in release_process.mdwn,
Oh yes.
> including the rhythm of major and bugfix releases.
I didn’t notice any such assumption while following that doc for 3.13.1. But it’s entirely possible that my trained brain adjusted things without me noticing consciously :) Is there a specific part of that doc that suggests so?
> At least: one is expected to know about the next major release,
Right → commit:d30a11a9253e61de8270e3996c4dcf4ab2e1f507
> and about the one after that!
Actually, not in cases in which this would be any harder than knowing about the next major release… but you’re right, the doc didn’t make this clear, and that surely didn’t help you follow blindly other instructions that should have been followed as-in → commit:dd14b7789b63152d00352e1e891a01c25b14d0d1 should help.
> But the next day […] to put 3.17 as the next major version in the devel branch, which I’m told would break the test suite.
I hope commit:5db3b5953ff853e9e1739bfcb6661b02fc197595 will help.
> I find it very hard to:
> decide what should be set through various environment variables. This has gotten better with the great MAJOR vs. BUGFIX renaming/clarification rounds though. But that started with some kind of cargo-culting, copying and pasting the RM’s file for the previous release, and trying to guess what should be bumped.
Understood. I would suggest that next time, you start this environment file from scratch wrt. the version numbers, and then follow the doc. This should help spot whatever remains unclear there :)
> understand all the implications of specifying this or that version at a given step. While this might be OK if one were able to follow the release process documentation blindly, experience for all RMing iterations I’ve taken part in shows that there are always exceptions and deviations that one should be prepared to operate.
ACK. commit:9b4284745a250975a992a99df55607933e5e6c28, commit:5db3b5953ff853e9e1739bfcb6661b02fc197595 and commit:c832a9710c15efe392a8f5750957746eaf90d90c should help.
> Therefore, I would very much welcome some kind of “definitive guide to versions” that would help RMs remember everything there is to know about versions/branches/etc.; or at the very least, help RMs operate consistent choices when they have to deviate from the release process documentation.
Wrt. versions, I’m afraid I wouldn’t really know what else to write in such a “definitive guide” than what I’ve added in the commits you’ll see in the “Associated revisions” section on the ticket. I’m happy to keep clarifying and adding whatever info is missing.
Wrt. branches, if something is missing on https://tails.boum.org/contribute/git/#branches, please let me know.
> Given how busy days 1 and 2 are, even with more experience, I don’t think I’ll ever manage to get post-release steps done before day 3
I’m pretty sure you will, once our doc deserves your trust more and you build more confidence in your own ability to assess whether you need to deviate from the doc :)
#4 Updated by CyrilBrulebois 2019-05-23 21:23:33
- Target version changed from Tails_3.14 to Tails_3.15
#5 Updated by intrigeri 2019-06-02 14:42:58
- Status changed from In Progress to Needs Validation
#6 Updated by CyrilBrulebois 2019-07-10 10:34:14
- Target version changed from Tails_3.15 to Tails_3.16
#7 Updated by CyrilBrulebois 2019-07-10 11:55:13
- Status changed from Needs Validation to Resolved
intrigeri asked me to revisit this ticket and close it if appropriate, which I’m doing now.
Spotting an old comment regarding the “3rd day”: I think I’ve grown confidence (hopefully not too much) but it seems I still find new ways to delay post-release steps (late Tor Browser import plus having to perform many tests due to having a single tester)… Maybe another time?