Changes between Version 27 and Version 28 of org/teams/NetworkTeam/ReleaseGuidelines

Jan 27, 2017, 3:00:48 PM (3 years ago)



  • org/teams/NetworkTeam/ReleaseGuidelines

    v27 v28  
    44The  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.
    6 [ 0.2.9 release tickets.]
     6[ Release schedule]
    8 == Release schedule ==
    9  * New stable release happens every 6 months
    10  * Next stable release date is: November 17 (Thursday)
    11  * Next Freeze date is: October 17 (Monday)
    12  * Alpha releases happens every month (???)
    13  * Triage for next release (0.3.0) - starts on freeze date of previous release (Oct 15th)
    15 === '''Open questions''' ===
    16 '''Should we split "0.2.9.x-final" into:'''
    18  * 0.2.9.x-release
    19  * 0.2.9.x-maint   ?
    20  * ''Nick says yes.''
     8== '''Open questions''' ==
    229'''Should we be working on stuff for the next release while one release is in -rc?'''
    4835=== Each week ===
    49 We will look at a query of the monthly tag TorCoreTeamYYYYMM
     36We give status updates at our Monday's meetings.
    51 Make sure nothing is waiting for review without a reviewer assigned to it.
     38We check the current''' review-group''' and:
    53 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:
     40 * Remind tickets owners to check tickets in 'revision' state
     41 * Ask for possible reviewers to tickets that are still without a 'reviewer' assigned to it
     42 * Validate tickets that are 'merge-ready' and can be removed from the group
    55  * It fixes a regression.
    56  * It is a volunteer patch that doesn't seem destabiliizing to merge.
    57  * It fixes a pre-existing significant bug. (Where "bug" and "significant" are narrowly construed.)
    58  * 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.]
     44We check our [ team rotation calendar] for who is in charge of 'bug triage' for that week.
    60 If  we like a ticket, it goes into the trac milestone, and we change the tag from "029-proposed" to "029-accepted".  If we don't, we  change the tag to "029-deferred" or just remove it entirely
     46We elect discussion topics for latter on in the meeting. These topics can be about a design implementation, or continuation of a discussion related to a proposal, or discuss the state of our releases, team processes and so on.
    62 == Prioritization for 029 ==
    63 Each release we will decide on what should guide us while deciding how to prioritize our work.
     48== Prioritization ==
     49Each release we will decide on what should guide us while deciding how to prioritize our work. This is done during ticket triage for the release - triages are done as we prepare for the release but also at any other moment we consider necessary in order to meet the release schedule.
    65 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.
     51We should always prioritize sponsor related work accordingly with the proposal timeframe. Bellow is a list of sponsors the Network Team has deliverables they are responsible for (each link takes you to our execution plan/deliverables roadmap):
    67 Then the other sponsor related work, then non-sponsor work.
     53 * Sponsor4
     54 * SponsorR
     56You can use the sponsor code to query tickets related to their deliverables on Trac.
     58Then we should look at non-sponsor work and prioritize it accordingly with the team capacity.
    71 === SponsorU Deliverables ===
    72 ==== ''Guard node improvements (task 4.1)'' ====
    73  * ''An  implementation of our improved guard node design, included in our  codebase, with improvements as found necessary during research.''
    74    * [ tor-guards-revamp]. (I suggest we don't use"tor-guard" for this, since that is for every single guard-related thing.)
    75  * ''Improvements to the testing of our route selection infrastructure. Risks and contingencies for guard redesign.''
    76    * [ tor-route-testing]
    78 ==== ''Improved public identity keys for Tor relays (task 4.2)'' ====
    79  * ''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).''
    80    * [ tor-ed25519-proto]
    82 ==== ''Better DoS resistance throughout the Tor protocol (task 4.3)'' ====
    83  * ''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.''
    84    * [ tor-dos-designs]
    85  * ''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.''
    86    * [ tor-dos]
    88 ==== ''Rigorous developer documentation (task 4.4)'' ====
    89  * ''A user’s manual for the compatibility and cryptographic layers at the bottom of the Tor code stack.''
    90    * [ tor-doc-lowlevel]
    91  * ''A  detailed high- and low-level overview of all modules in Tor, their data  flows, their intended interactions, and their actual behaviors.''
    92    * [ tor-doc-modules]
    94 === [[BR]]SponsorS Deliverables ===
    95 ==== Pluggable Transports: ====
    96 Task 1 ISponsorT work): Write 2 evaluations (new ones)
    98 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.
    100 Task 3 (SponsorS): Tor side pluggable transport­ related (and other) improvements.
    102  * I've been using tor-pt and tor-bridge for these.
    104 Task 4 (SponsorS): Pluggable transport R&D (Catch-all)
    106 ==== Core Tor: ====
    107 '' "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."''
    109  * We're splitting this into
    110    * 1b. [ tor-tests-integration]
    111    * 1a + 1c. [ tor-chutney-usability]
    113 ''"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."''
    115  * 2. [ tor-tests-coverage]
    116  * 2a.[ tor-tests-unit]
    117  * 2b. [ tor-client-scripting]
    118  * 2c. [ tor-tests-stem]
    120 ''"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."''
    122  * 3a. [ tor-controller-extension]
    123  * 3b. The keyword [ tor-modularity] tracks some stuff that we ''had'' associated with this area, but none of it is a must-do deliverable.
    125 === SponsorR Deliverables ===
    12662== Team Capacity ==
    12763How much the team can actually do.
    15389 * 1 hr = 0.1 point
    15490 * 5hrs = 0.5 points
    156 == Making triage stick ==
    157 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.
    159 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.
    161 Are permissions of some kind the answer?
    163 Nick says "yes", so long as:
    165  * There's some way to get external/unplanned patches merged.
    166  * Surprise bugs can get fixed.
    167  * We do this as discussion not dictatorship.
    168  * We revisit periodically.
    169  * We can meet other teams' needs.
    170  * We can add subtickets as we discover unexpected prerequisites
    172 For now, we will use the "029-proposed" ticket to nominate stuff for 0.2.9.  The following things can be fast-tracked in while we're in development-mode:
    174  * Dependencies of things already in the 0.2.9 milestone. (Use child-tickets!)
    175  * Serious, severe bugs.
    176  * Regressions.
    177  * Stuff that will take less than 15 minutes
    178  * Needs-review stuff with an easy-to-review patch that's externally written.
    179  * "we realized that this is actually a must-do funded item that we forgot to include, whoops"
    180  * Code removal