-
Notifications
You must be signed in to change notification settings - Fork 686
Sprint Planning Meeting 2020 02 20
What we said we would do:
- Address recently discovered and WIP release blockers.
- Release SecureDrop 1.2.1
- Aggressive testing in dev, including with >100 - <1000 sources. Identify final set of release blockers for next sprint
Release blockers are tracked here: https://docs.google.com/spreadsheets/d/1dP5PMNg7I95iBnf7WRA_7p6MqgkpE3lnbIC7w_hwQiE/edit#gid=0
We resolved the following release blockers:
- SecureDrop 1.2.1 release: https://github.com/freedomofpress/securedrop/issues/5121
- "Not authorized" error while printing: https://github.com/freedomofpress/securedrop-export/issues/53
- Enforce dom0 salt state in updater: https://github.com/freedomofpress/securedrop-workstation/issues/427
- Skip unnecessary update checks: https://github.com/freedomofpress/securedrop-workstation/issues/402
- Security reminder script for running updates: https://github.com/freedomofpress/securedrop-workstation/pull/445
- Legacy updater removal: https://github.com/freedomofpress/securedrop-workstation/pull/430
- Unnecessary keyring churn in client: https://github.com/freedomofpress/securedrop-client/issues/757
- Continuous syncs: https://github.com/freedomofpress/securedrop-client/pull/739
- Kernel update: https://github.com/freedomofpress/securedrop-workstation/issues/441
These ones are almost done:
- Rebuild qubes-template-securedrop-workstation for production: https://github.com/freedomofpress/securedrop-workstation/issues/424
In addition, we landed the following changes:
- Queue refactoring: https://github.com/freedomofpress/securedrop-client/pull/786
- Signal/slot fixes (fixed several client issues): https://github.com/freedomofpress/securedrop-client/pull/772
- Decryption error handling: https://github.com/freedomofpress/securedrop-client/pull/768
- Switch to reprepro, added Buster channel for workstation
- Unbroke the client a couple of times (AppArmor fixes, SDK update for network handling)
- and more.
We also agreed on several potential pre-release changes needed to the network error handling logic, as recapped in this doc: https://docs.google.com/document/d/1-Y6eK0q6Bpxe4IcGFdyVZ2rqXxRqAFCbiiapEWqfUuE/edit#heading=h.fqn1lxk5hyax
Team comments and observations:
What worked well:
- New signing workflow (for prod tags) is fairly straightforward, saves a lot of time
- Least infra involvement we've ever had in an SD core release, let's keep going in that direction
- Good hand-off of the issues/reviews at the end of the day (kushal) +1 yeah I appreciated the feedback from folks -- thank you..! (Nicholas)
- Agreed, hand-off between "shifts" has been solid!
- Useful engineering discussion around networking error handling- using google doc helped vs using gitub issues
- Lots of focus on creating STRs and fixing bugs for the client
- Again many large changes merged (logging PR, template rebuild and prod packages), excellent collaboration
What can be improved:
- SD core release management docs could use some updating, clarifying of timing
- Would be awesome to have baby-steps STR for UI bugs -- sometimes I've simply not had the context needed to recreate a bug and since you're all asleep by the time I wake up I'm left guessing. ;-)
- Splitting up PRs so they're smaller and not sitting around too long (this is mostly for me, e.g. #666)
- This is small, but I think comments in the config file for each attribute would help admins/devs, e.g. what does "environment" do? [JSON doesn't support comments; for now have to handle in README]
What's still a puzzle:
- The functional tests are getting there, but it's still a pain to write new ones since there are still several unknown corners around how pytest-qt works. This is a work in progress.
- qmemman - qubes-memory-manager service, runs in dom0
- Conor: I now check this as part of my morning routine and it's ALWAYS failed, have a script
- Conor noticed that during updates, Qubes sometimes under-resources VM because the Qubes memory manager does not appropriately balance memory usage. qqmemman restart resolves
- Having/specifying more memory seems like a really easy fix -- everything is better with 32+GB
- we could give sd- qubes a higher base memory
- I found myself needing guidance around getting the latest workstation because I wasn't sure if running qubes-dom0-update was necessary in order for a feature I was most insterested in (auto-attach) to work. Maybe some more cross-team deep dive engineering discussions would be helpful.
- Mickael: Usually a make clone && make all && make test should be sufficient while using dev environment.
- ACTION: Consider switching to prod RPMs while using client dev builds in sd-app or sd-dev
- Need knowledge-sharing around Salt in Qubes or other aspects of provisioning/release mechanics
- ACTION: Conor/Jen to consider what kind of knowledge share would be most useful in the near term
2020-02-24 to 2020-02-28: Time off: Kushal
2020-02-24 : New FPF staff member starts (Senior DevOps Engineer)
2020-02-26 : Blog post announcement of SecureDrop Workstation pilot / technical backgrounder
2020-02-28 : Time off: Conor
2020-03-02 : Feature freeze for 0.2.0beta (TENTATIVE); soft transition to Kanban mode during QA
After sprint period:
2020-03-02 to 2020-03-06: Kev at on-site
2020-03-05 to 2020-03-09: Conference: Kushal
2020-03-04 to 2020-03-20: Ro conference/on-site/ 3 days PTO, away from SD servers (re QA)
2020-03-10 : Tails 4.4
2020-03-16 to 2020-03-20: (approx) Conor in PDX
2020-03-16 : SecureDrop Workstation 0.2.0beta release
2020-03-23 : First provisioning of SecureDrop Workstation (Kev, Ro)
2020-03-30 : Second provisioning of SecureDrop Workstation (Conor, Martin)
Third provisioning of SecureDrop Workstation (TENTATIVE - DigiSec team; maybe Kev again)
2020-04-06- 2020-04-10 : Possible SD installation/on-site (unlikely, NYC)
Sometime in April : SecureDrop 1.3.0 - April 7 is a Tails release so that's a good target for 1.3.0
April - July : Cont'd check-ins with pilot participants
Time check: https://docs.google.com/spreadsheets/d/1DIt4V6p2rOd4b-BigFIOZXoqxCUoZi6-PpKDwlNw3DM/edit#gid=0
Proposed:
- Resolve remaining release blockers.
- Smaller bugfixes can be handled alongside blockers and during QA.
- Complex stretch goals are a lower priority and should be started later.
https://docs.google.com/spreadsheets/d/1ueb4lcW0Qte7WMywTw9qJ3FWiHioyqNop017_tEZTlU/edit#gid=0