Skip to content

Retrospectives 2021 03 17 SecureDrop 1.8.0

Jump to bottom
Erik Moeller edited this page Mar 18, 2021 · 1 revision

SecureDrop 1.8.0 retrospective - 2021-03-17

Facilitator: Mickael

Participants (alphabetical): Allie, Conor, Erik, John, Kevin, Mickael, Ro

What worked well

  • great cooperation on critical issue found late in QA+1

    • +1, also complex changes (paxctld, kernels, unattended-upgrades) introduced relatively late

  • difficult release that took a lot of coordination and communication+1 +1

  • dual-distro support landed, we have a clean install and a backup story for migration

  • team made good calls around release reliability: some delays to understand functionality more deeply. strong communication around investigation and blockers.

  • I had no issues following the docs to migrate my long-running canary instance to Ubuntu 20.04, and have not observed any issues since then :)

  • Impressed that we were able to ship a new kernel as well, which should help with future hardware compatibility+1+1

  • translator feedback was incorporated for the release, and there was more than usual. we had a bit more time, especially with pushing the release back.

What can be improved

  • although we handled the last-minute changes well, we were still debating some pretty big decisions quite late in the game; potential for errors/bugs/stress +1

    • Be more explicit about changes that can or that we should back out, be more comfortable with backing out changes

  • significant changes like cron-apt -> unattended-upgrades warranted a walkthrough at review time, too much was news during QA+1+1+1+1+1

    ACTION: Flag large/complex PRs, careful test plan creation, provide pre-release testing.

    • plan requirements/specification stage

    • also mentioned was having the release manager call small meetings with PR devs while writing up the release test plan +1

  • cooperation was great, coordination could be better. there was a lot of dogpiling on issues.

    • possible ACTIONs:

      • Better communications, better coordination and better assignments on PRs
      • comment in #securedrop or gitter?
      • comment on the issue/pr +1
      • Use assignment more consistently
      • three sprint goals in the Standup template

  • Not sure that docs in a separate repo is leading to good outcomes (Would like to hear more about this?)personally guilty of this for sure, but having a separate PR for UI changes etc feels like it's increasing overhead.

    • separate docs repo is good for volunteer prs, quick merges, issue organization

    • ACTION: File issues in the docs repo

    • ACTION: Label PRs with needs-docs (and link to corresponding docs issue^)

  • docs process could have been less time-intensive and/or clearer; a lot of revisions and a lot of time back-and-forth+1

    • would it be helpful to merge more frequently into "latest"?

    • it could be helpful to discuss complex procedures at a high level (perhaps meeting) before writing them up in detail, to confirm we are on the same page about what is required (backup/restore, e.g.)+1+1

      • (backup and restore) procedures were finalized late, and documentation was impacted by this delay

  • QA coverage was challenging thanks to dual-distro - will probably be less so once on Focal-only, but further automation (i.e. paxtest in testinfra) would help +1

    • ACTION: more test automation, automate "basic server testing" as much as possible.

  • If/else conditional logic being added all over the place, which warrants significant clean up

  • release management docs are diverging a bit from actual process, could merit some attention

What's still a puzzle

  • the backup/restore story is still quite complex in practice, and I'm wondering what we can do to simplify things for admins -- e.g., more consistent management of Tor authentication and service data, SSH keys, etc.

    • ACTION: Open issue tracking consolidate tor secrets/configuration, store that information in backups, post tarball creation (we also discussed on putting this on servers)

  • universe packages in Focal

  • support for multiple OS releases is still pretty messy. if we think we might have to go through another Ubuntu upgrade, we should clean it up instead of just dropping the Xenial-specific bits and having to figure it out again next time+1

    • simplifying artifact we ship (container?)

    • the underlying host will need to be configured

    • ACTION: update RM docs to indicate using qubes dispvm to build

  • how can we pare down mammoth docs reviews into smaller pieces?

Clone this wiki locally