Skip to content

Sprint Planning Meeting 2020 02 20

Erik Moeller edited this page Feb 20, 2020 · 1 revision

Sprint Planning Meeting, SecureDrop, February 20, 2020

Sprint timeframe: Beginning of Day (PST) 2020-02-20 to Beginning of Day (PST) 2020-03-04

0) Retrospective

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:

These ones are almost done:

In addition, we landed the following changes:

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

1) Review important dates and time commitments

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

2) Agree on goals for this sprint

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.

3) Task selection and estimation

https://docs.google.com/spreadsheets/d/1ueb4lcW0Qte7WMywTw9qJ3FWiHioyqNop017_tEZTlU/edit#gid=0

4) If we have time: Board review

Clone this wiki locally