= Network team meeting notes from Rome (March 10-11)
== Summary of "Decided" things
We'll pre-assign rotations in advance to spread them fairly.
We'll pre-assign reviews, (George and David and Isa) to get them fairly spead, and assigned to people who know something about the code.
(It's okay to get help with your reviews! It's okay to ask for help! It's okay to say "this is a limited review based on my understanding of x y and z")
We'll start each meeting with: * a roadmap checkin * overview and acknowledgement of assigned reviews * overview and acknowledgement of assigned rotations
We'll make a list of daily/weekly tasks that someone/everyone should do daily/weekly.
We'll all check-in on #tor-dev every day with a line saying we're here, and what we're working on, as: /me status: working on the wombat-sorting logic (To decide later: Should we have a bot somewhat like the tor-status bot to collect these?)
New rotation role: "community hero". Interacts with user questions, finding answers if they don't know them. Helps out new volunteers with patches, etc.
Expectation: code review same week, or discussion about not same week.
We're going to have the roadmap be MINIMALIST this time, containing ONLY sponsored and essential stuff. If we get that done ahead of schedule, we can do other stuff too.
Let's not spend more than 1 day on anything without getting it into the roadmap.
Let's link all our pad/sheet documents from some single place. Public when they can be; private otherwise.
== Rust "time"line:
-
Some rust in Tor. [DONE]
-
Current phase.
2A. Optional features may require rust. These must be safe-to-have-some-users-not-use. FOR EXAMPLE:
* Some crypto modules written in rust for performance.
* Privcount in rust.
* Postquantum -- can it safely be rust-only?
* Multithreaded crypto (not sponsored, not in-scope).
* integrated external code (like vanguards) (not yet)
* (We SHOULD NOT actually do unsponsored/unessential stuff here)2B. NECESSARY coding standards and infrastructure exist in Rust, such as: [current phase]
* Definite FFI rules.
* Error-handling rules.
* logging rules.
* linking/build modules.
* mechanism to test implementations against each other.
* mechanism to keep interfaces (and types) in sync.
* test coverage for rust code.
* (We SHOULD NOT actually do this before we need it.)2C. Builders build our packages with rust. Including: TB, something mobile, debian. We fix their pain-points and bugs whatever they seem to be.
-
Tor yells at you if built without rust. We announce a must-use-rust date.
-
Tor may require rust.
== The big pile of bugs
What belongs in current milestone:
-
Roadmap items
-
Sponsored
-
Essential, non-sponsored
-
-
Surprises
-
Regressions
-
Security bugs
-
"Showstopper" bugs
-
Major incident response
-
Uncertain if it belongs in current milestone. Decide on case-by-case ad hoc basis for now. * Surprise code! (volunteer patches) * Little issues
Process: when you put something in the current milestone if it isn't on the roadmap, we mark it until it is discussed.
Meetings: Let's discuss week-by-week diff of which tickets are new, and make sure they all belong.
Managing the big pile: * Maybe, it's okay to have a big pile! * But maybe we should revisit big pile
* As part of roadmapping?
* We could classify pile based on areas/subsystems?
* We could have pile classification as an ongoing task
* We could have pile classification as a periodic task== The list of areas:
All the stuff under "anonymity" could get folded under deanonymization attacks.
* Collect the various attacks/defenses we know about, refer to them as we work.The top-level areas categories look even better.