-
Notifications
You must be signed in to change notification settings - Fork 685
Sprint Planning Meeting 2022 04 13
- Get first round of Source Interface design updates to "Ready for Review"
Status: Marked as ready for review, first round of review by Kunal completed
- Follow up with news organizations regarding spam mitigation and spam survey responses.
Status:
-
Survey findings synthesized
-
Potential blog post under discussion
-
News orgs notified about availability of new features
-
QA and ship SecureDrop Workstation and SecureDrop Client releases
Status:
- SDK released
- Client RC is under QA, release has been rescheduled to next week
- Config RPM has been updated yesterday
Facilitator: Kunal
What worked well:
- More QA for the SDW than we've ever had
- Marek and the Qubes team is being super responsive during our 4.1 compatibility testing and SDW release testing+1+1+1
- pairing on workstation, client, and sdk release mechanics was really helpful
- great cooperation on the hotfix +1+1+1+1
- the SD Server point release process seems to be getting faster/smoother (possibly because there was no kernel bump this time). Historically they may actually have been quicker but with more of a YOLO factor, I think this one hit the sweet spot in terms of QA/response time
- There was a big push to transfer knowledge from Conor to me (Allie) and from me to Ro, etc., so that was a big win this sprint (+1!), but overall less checking of the boxes perhaps
- We consolidated client and SDW acceptance testing, but we still need to iterate on making improvements there, e.g. SDW Updater check using the preflight updater rather than directly installing the RPM
- SD dev meetings continue to be great (may be a repeat from last retro but still)+1+1
What can be improved:
-
Updater behavior in Qubes remains problematic. +101
- do we need QubesOS system testing too? (Functional tests of vms/updates etc)?
-
onboarding during (a) release cycle(s) has been challenging +1 (felt like folks on the team had a lot to juggle with during my ongoing onboarding) +1 (there could be more orientation planning around our release cycle); I don't know if we've given our new folks enough attention?
-
Concerned that in practice release calendar may have us feeling like we're either releasing or QAing every other week...but maybe just something to keep an eye on.
-
Would like big picture view of the technology [Orientation improvement]
-
-
gpg +1+1
-
test datasets - loaddata.py does not precisely simulate the source creation experience+1 +1; would like to put a little time into this since this bit me during testing
-
Also loads an instance with an unrealistic read/unread scenario for the client
-
And breaks my staging server sometimes :[
-
ACTION: Open issue to track potential improvements
-
-
engagement with translators is still a concern, would like to get some positive steps in place before next server release
-
The release process for the SDK is more complicateed and time consuming than it needs to be, and overall packages take a long time to properly build and release.
-
Time estimation: is it just me? :) +1+1+1
-
For me, I haven't missed estimating how long it takes for each task during sprint planning, but that could be helpful: bring back assigning points to tasks. Then we might need to make sure we add all tasks on the project board (which we're definitely not doing).
-
We've also been doing a lot of training while working on tasks, so that could explain why time estimation doesn't seem right
-
→ context-switching: plan to work on X, have meeting about Y, get pulled into Z :-) +100+1(from the outside looking in)
-
One way to make this visible: standup could be: (1) What I intended yesterday; (2) What actually happened yesterday; (3) Therefore, what I intend today...
-
We could also have a % of our time that we don't allocate, just to allow for 'surprises'
-
What's still a mystery:
-
Now have a workaround for syncing unsupported SecureDrop languages to Weblate...but can't reconstruct how new languages managed to get added in the past. :-\
-
How best to implement dual-channel repo support for buster->bullseye transition on Workstation
-
What does it take to build a custom template for Qubes? (Knowledge share incoming)
-
Q2 goallzzz? and resource splits across SD and SDW projects to achieve said goals+1+1
- Making room/time/capacity for architectural discussions that will facilitate both new features and fixes +1
-
Can we script/automate more of the workstation release mechanics?+1 (also potential improvements around our package builder logic and automating build logs, etc.)
- Erik alternating 48+PTO / 410, always off Fridays
- Conor ~4*8 until April 28
- Cory @ 4*10 Mon-Thu
- Allie @ 3*10 Mon-Wed
- Ro @ ~4*8-10 Mon-Thu
- Giulio ~20 hours/week
- Gonzalo on break, probably back in late April
- Ro ? some PTO in May, TBD
- Abigail's OOO appointments: 4/25 10:30-12:30, 5/9 8am-11am, and a few more that are getting scheduled this week.
- KOG offset 1/2 day of weekend QA time tmw (04/14)
- Michael PTO tomorrow (04/14) for travel
2022-04-15: Holiday (US/Canada)
2022-04-18: Holiday (Australia/France)
2022-04-19: SecureDrop Client release
After sprint:
2022-04-28: Conor's last day :-(
2022-05-03: Tails 4.30 or 5.0 (see https://tails.boum.org/contribute/calendar/)
QA begins for SecureDrop 2.4.0
2022-05-17: SecureDrop 2.4.0 release
2022-08-02: Debian Buster EOL / Qubes 4.0 EOL
- Vulnerabilities triage: Michael
- Support triage: Ro
Proposed:
- Complete SecureDrop Workstation release train
Rationale: Release trains always take priority over non-critical ongoing work.
- Allie, Ro, Erik, Cory
- Land first round of Qubes 4.1 compatibility improvements
Rationale: 4.0 EOL coming up in August, Whonix EOL for 4.0 on April 20.
- Ro, Erik, Michael, Kev will be doing 4.1 testing
- Land Source Interface design changes (round 1)
Rationale: Precondition for the "flow inversion" work, which itself is expected to significantly simplify the user authentication story for sources.
- Michael, Kunal, Kev, (Cory)