Version 7 (modified by arma, 5 years ago) (diff)


Set of guidelines for releasing Core Tor 0.2.9

The goal of this guidelines is to ensure that all members of the team have the same expectations. Release process can be super stressful for the team, and by having guidelines we can remove a lot of stress by creating consistency and structure to our release process.

0.2.9 release tickets.

Release schedule

  • New stable release happens every 6 months
  • Next stable release date is: October 1st
  • Next Freeze date is: September 1st
  • Alpha releases happens every month (???)
  • Triage for next release (0.3.0) - starts on freeze date of previous release (Sept 1st)

Open questions

Should we split "0.2.9.x-final" into: * 0.2.9.x-release

  • 0.2.9.x-maint ?
  • Nick says yes.

Should we be working on stuff for the next release while one release is in -rc?

  • Nick suggests that everybody assume they will be on bugfix during -rc time.

Should we be working on stuff for the next release while there are leftover tickets from the last one in needs_review/needs_revision?

  • Nick thinks that reviewing and fixing leftover tickets should get done early, and should get some priority.

Team Routines:

Each month

We plan our work in a monthly basis using the tag: TorCoreTeamYYYYMM

First week of the month:

We should elect the tickets we will work in that month. These should be tickets from the 0.2.9 milestone. During the election process we should make sure that tickets has:

  • an owner
  • a reviewer
  • estimation points (small, medium, large)

Last week of the month:

We should review the state of the tasks of the month that is ending and start moving work we won't finish before the end of * look at closed tickets from previous month and apply actual points to it

  • start building an alpha release for the month (?????)
  • move open, or in review tickets to the next month tag

Each week

We will look at a query of the monthly tag TorCoreTeamYYYYMM

Make sure nothing is waiting for review without a reviewer assigned to it.

We'll look at tickets marked as "029-proposed". These are tickets that we didn't have on 1 April which nonetheless we think should be considered for the release. A ticket is potentially suitable to be included if:

  • It fixes a regression.
  • It is a volunteer patch that doesn't seem destabiliizing to merge.
  • It fixes a pre-existing significant bug. (Where "bug" and "significant" are narrowly construed.)
  • It can be fixed in less than 15 minutes, including fix, review, merge, and possible debug. [Nick might just skip the whole process for ones like this when he feels like it.]

If we like a ticket, it goes into the trac milestone. If we don't, we change the tag to "029-deferred" or just remove it entirely

Prioritization for 029

Each release we will decide on what should guide us while deciding how to prioritize our work.

For 029 we are guiding ourselves by giving priority to the tasks associated to deliverables we must complete for contracts ending on Q3 2016. These are SponsorU and SponsorS deliverables, which we are listing below.

Then the other sponsor related work, then non-sponsor work.


SponsorU Deliverables

Guard node improvements (task 4.1)

  • An implementation of our improved guard node design, included in our codebase, with improvements as found necessary during research.
    • tor-guards-revamp. (I suggest we don't use"tor-guard" for this, since that is for every single guard-related thing.)
  • Improvements to the testing of our route selection infrastructure. Risks and contingencies for guard redesign.

Improved public identity keys for Tor relays (task 4.2)

  • Protocol support for improved identity key infrastructure: clients connecting to a server can verify that they are connecting to the server with the desired identity key(s), and can instruct midpoint servers to extend to the server with the desired identity key(s).

Better DoS resistance throughout the Tor protocol (task 4.3)

  • One or more design proposals for improvements to the Tor protocol to avoid the most important denial-of-service attacks against Tor networks. These will provide sufficient detail and rationale so that other implementations of the Tor protocols, and designers of other anonymity tools, can use them to strengthen their systems as well.
  • Implementations of the most beneficial of these proposals (in terms of cost-benefit ratio), so as to render Tor servers and the Tor network less susceptible to denial of service. The details of these will be defined more fully after the analysis in the steps above.

Rigorous developer documentation (task 4.4)

  • A user’s manual for the compatibility and cryptographic layers at the bottom of the Tor code stack.
  • A detailed high- and low-level overview of all modules in Tor, their data flows, their intended interactions, and their actual behaviors.

SponsorS Deliverables

Pluggable Transports:

Task 1 ISponsorT work): Write 2 evaluations (new ones)

Task 2 (SponsorS, aka this direct contract): Maintain and extend obfsproxy, obfs4proxy, obfsclient and other PT codebases as needed, and assist developers and researchers who wish to use our frameworks to do relevant research.

Task 3 (SponsorS): Tor side pluggable transport­ related (and other) improvements.

Task 4 (SponsorS): Pluggable transport R&D (Catch-all)

Core Tor:

"The first task is [1a] streamlining and automating the process of launching a complete testing Tor network, including Tor directory authorities, relays, bridges, clients, and hidden services, as well as client applications and destination services like websites. [1b] We need to continue to identify and resolve bugs in Tor's "testing network" configuration. [1c] We need to improve packaging and portability for these tools, so other researchers and developers can reproduce and extend our results."

  • If we're doing all of these together, we should call it:
    • tor-testing-integration
  • We could also split this into:
    • 1a + 1c. tor-chutney-usability
    • 1b. tor-tests-network

"The second task is designing and scripting an automated test suite to exercise and stress as much of Tor's functionality as possible. These tests should come in the form of [2a] a) standalone unit tests, [2b] b) scripted clients that perform specific actions and expect certain results, and c) [2c] Tor controllers that exercise the control port interface as much as possible to observe and modify Tor's internal state. This test framework will allow us to investigate and reproduce bugs reported in the wild in a safe (with respect to user privacy) and controlled environment. We should also focus on getting our test framework to the point where other developers can devise and run their own tests."

  • 2. tor-tests-coverage
  • 2a. tor-tests-unit
  • 2b. tor-client-scripting
  • 2c. tor-tests-stem

"The third task, in parallel with the first two, is to extend Tor's controller interface to allow better monitoring. So far the control protocol has focused on exposing client state to local controllers (like the graphical interface); we will change it to export more details for relays, directory authorities, and hidden services as well. Combined with build automation (a separate project), the extended interface will also provide a more powerful framework for continuous evaluation of performance, scalability, and bandwidth overhead."

  • 3a. tor-controller-extension
  • 3b. tor-modularity

SponsorR Deliverables

Team Capacity

How much the team can actually do.

Out of 5 days in a week how many do we actually code?

If we leave 1 day for working on proposals (writing or reviewing), and another day for code review, we should allocate 3 days out of the week for working on tickets.

Based on that we are using the following values for ticket's points:

  • large == something that takes more than a week (3 days of work) and less than a month (4 weeks of work or 12 days of work) / more than that the task should be breakdown
  • medium == 1 week or 3 days of work
  • small == something that can be done in one day of work or not longer than 2 days of work (for instance, you should be able to fit 2 small tasks in a week)

Making triage stick

Nick says: We can't get much benefit from triage unless we actually work on the triaged-in things. And we really haven't been doing that much in the past.

If we use the same milestone to indicate "We have decided we should do this in 0.2.9" and "Somebody suggests that we should do this in 0.2.9" we won't be able to keep track of what's what.

Are permissions of some kind the answer?

Nick says "yes", so long as:

  • There's some way to get external/unplanned patches merged.
  • Surprise bugs can get fixed.
  • We do this as discussion not dictatorship.
  • We revisit periodically.
  • We can meet other teams' needs.
  • We can add subtickets as we discover unexpected prerequisites