Skip to content

Sprint Planning Meeting 2020 10 01

Jump to bottom
Erik Moeller edited this page Oct 1, 2020 · 1 revision

Sprint Planning Meeting, SecureDrop, 2020-10-01

Sprint timeframe: Beginning of Day (PDT) 2020-10-01 to Beginning of Day (PDT) 2020-10-15

0) SecureDrop 1.6.0 Check-In

  • Kev has fix ready for file handling issue, see https://github.com/freedomofpress/securedrop/pull/5549 - Kev will recommend whether or not to include in 1.6.0, if so, without string changes
  • Test dependency update pending
  • No QA today, revisit at RC2 level
  • Pre-release messaging was dispatched yesterday
  • Docs changes still pending

1) Retrospective

What we said we would do:

  1. Land critical changes for SecureDrop 1.6.0 and test them extensively.
  • Server-side changes for seen/unseen. Need to ensure clean migration for long-running instances

Sprint goal fully met. All server-side changes landed, testing in progress per test plan.

  1. Land preparatory changes to complete template consolidation in the next sprint.

Sprint goal partially met. Initial research on update strategy completed:

https://github.com/freedomofpress/securedrop-workstation/issues/471

Smaller preparatory steps for full consolidation still pending (work on SecureDrop Client hostname check in progress).

  1. Switch staging environment for Ubuntu 20.04 to grsec-patched kernel

Sprint goal fully met.

Additional accomplishments:

Other team comments

What worked well:

  • Running testinfra in Tails over tor is so much better than manual checks for QA (+1 +1)
  • pre-release comms being drafted early :) -- less hectic than 1.5.0
  • mickael: great collaboation and testing of complex serverside changes and migration
  • initial impression on separate docs repo: it's actually quite convenient!

What can be improved:

  • [ro] earlier hardware testing: kev was on it, but the deadline snuck up on me. Testing well in advance + overal hardware support strategy (this is in progress already)
  • mickael: improvements to qa_loader (e.g. adding seen/unseen information, maybe adding invocation to upgrade testing scenario) +1
  • Kushal: We should update the devops dependencies regularly, the random pain due to old version of things means we can ask for help in upstream channels (say molecule or testinfra/pytest).
  • Conor: Kernel debugging for hardware support, let's plan to over-provision those test devices next time. Ro's been fighting an uphill battle and no one else has the exact same hardware, so she's got to document and report everything, with no one to pair directly with
  • John: For API changes we should budget development time to script QA for a pretty significant net time savings.

What's still a puzzle:

  • Conor: Can we pull off template consolidation in one-pass? Kev & Conor are increasingly optimistic, but have yet to test in practice. (+1 +1)

  • [ro] Continued hardware support conversations (including decision to continue or not with NUCs)--let's have them as a team when the dust settles?

    • (Conor) +1, although even before the dust settles, I'd advocate for ordering more and different (FOSS-friendly) hardware
    • (Kev) I'm less into the FOSS-friendly H/W angle - if the issue is access to said hardware for corporate purchasing, then it might be worth spending time on process to allow users to check for kernel compatibility against hardware they plan to use. (+1)
    • (Kushal) We have to make sure hardware is available internationally.
    • (Ro) Good subject for dedicated team conversation
    • (Erik) We'll discuss at future support sync. We can potentially combine a very SD-friendly recommendation with tooling that news orgs can run.

  • Are we going to be able to remove all the manual QA steps in the 1.7.0 test plan? (+1)

    • +1, manual testing might make sense for 1 or 2 scenarios, but further automation and tracking results in the matrix could help us reduce the amount of scenarios we need to go though
    • (though I think not) What about some Selenium+tor for QA steps?

Learning time debrief

  • (Erik) Not much progress on Qt, but spent some learning time on my Signal setup (Firejail + second Android profile) so I can switch to Signal work account; will aim to document for the org

  • (Conor) Brief spike on trying to simplify the kernel build process https://github.com/conorsch/kernel-builder - Have been test-driving this new setup with Ro during hardware support efforts

2) Review key dates and time commitments

2020-10-02              : FPF Holiday
2020-10-07              : SecureDrop 1.6.0 Release
2020-10-12              : US/Canada holiday (Thanksgiving/Indigenous People's Day)

After sprint period:

2020-10-26              : Threat model discussions with auditors begin
2020-11-16              : SecureDrop Workstation audit begins

PTO check-in:

  • John: maybe a day, TBD
  • Mickael: 1 day, TBD
  • Erik: 1 day total, October 9 & 16

3) Agree upon top priorities for the next two weeks

  • Release SecureDrop 1.6.0
  • Finish template consolidation and prepare for release
  • Run Focal (Python 3.8) application tests in CI

4) Select and estimate tasks

https://docs.google.com/spreadsheets/d/1I3vyZ-nxMr0aB8z-Hh-ibeM0SdHEXrtENxUAY9ab6V4/edit#gid=808635985

Clone this wiki locally