From the top of my head there only is one thing I will not be able to do which is signing the packages and moving them to apt.freedom.press. Who will be available to do that?
Publishing the packages for testing should not be a problem as https://apt-test.freedom.press/ can be replaced by https://packages.securedrop.club/ in the Q/A process. It would not have worked for 0.8.0 because the grsec kernel changed and that makes things slightly more difficult. But we are planning to upgrade the grsec kernel for 0.9.0 (unless this is missing from the 0.9 milestone?) and the bot creating the packages whenever a tag is published is going to remove a little bit of manual work.
Am I missing something?
Most of the release management work is around documentation, communication and review/merging, which are privileges you already have as a maintainer. When you will branch 0.9 branch from develop, you will have the ability to write to that branch.
We do not have plans to update the kernel image for this release (unless there’s a serious kernel vulnerability that would need to be addressed). However, we might change dependencies in the kernel metapackage, which is handled by the
build-debs makefile target.
We do not have plans to update the kernel image for this release (unless there’s a serious kernel vulnerability that would need to be addressed). However, we might change dependencies in the kernel metapackage, which is handled by the build-debs makefile target.
Unlikely in my mind that we will remove the dependencies, given that there are still a small number of orgs rolled back. We hope to resolve that by the time 0.9.0 ships, but no guarantees.
As for the apt-test flow, we’d have to change the URLs for the staging machines to pull from packages.securedrop.club if we use that. Happy to grant you access to apt-test if that’s helpful for your workflow—we use aptly to manage the repos. We’d have to set up some time together to sync on the relevant procedures. Holler if that’d be useful to you, more than willing to accommodate.
During final release, as @mickael stated, it’ll likely be both @redshiftzero and myself assisting with the final bits to make it live. We’ll also have the support team coordinating messaging on Twitter, the SecureDrop Blog, and the Redmine support portal for mailing notifications to Admins onboarded there.
Thanks for taking on Release Manager this time around! Looking forward to it.
As we get closer to the release, I suggest we set aside some time to discuss the QA process and responsibilities. For the last release, we started using a QA matrix in Google Docs (I tried Ethercalc, but it’s just too terrible). Kevin will play an increased role in this QA process, but note that he has a prior PTO commitent for the week of August 27, just before the release.
During the last release, we tested both on supported hardware and on a number of additional configurations, given the risks associated with the kernel update. We’ll likely want to continue to test on the ProLiant and the PowerEdge, at least until we have an official rack-mounted server recommendation. We may or may not be able to share some of those testing responsibilities using remote management tooling; that research is underway.
I will unfortunately not be available to drive the 0.9.0. There hopefully is enough time to find a replacement. Volunteers?
Just chatted with @emkll about this - he’s going to RM for 0.9.0 and I will do 0.10.0.
Great news! @kushaldas will be release manager for 0.11.0. If there is a lot of localization work to be done for that release then we might sub in someone else for localization manager - TBD.