Changes between Version 1 and Version 2 of org/teams/NetworkTeam/ReleaseGuidelines


Ignore:
Timestamp:
Apr 11, 2016, 2:54:48 PM (4 years ago)
Author:
isabela
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • org/teams/NetworkTeam/ReleaseGuidelines

    v1 v2  
     1[TOC]
     2
    13= '''Set of guidelines for releasing Core Tor 0.2.9 ''' =
    24The  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
    35
    4 == .Release schedule ==
     6== Release schedule ==
    57 * New stable release happens every 6 months
    68 * Next stable release date is: October 1st
     
    1517 * ''Nick says yes.''
    1618
    17 '''Should we be working on stuff for the next release while one release is in -rc?''' 
     19'''Should we be working on stuff for the next release while one release is in -rc?'''
    1820
    1921 * ''Nick suggests that everybody assume they will be on bugfix during -rc time.''
    2022
    21 '''Should  we be working on stuff for the next release while there are leftover  tickets from the last one in needs_review/needs_revision?''' 
     23'''Should  we be working on stuff for the next release while there are leftover  tickets from the last one in needs_review/needs_revision?'''
    2224
    2325 * ''Nick thinks that reviewing and fixing leftover tickets should get done early, and should get some priority.''
     
    2527----
    2628== Team Routines: ==
    27 ===  ===
    2829=== Each month ===
    2930'''We plan our work in a monthly basis using the tag: '''    TorCoreTeamYYYYMM
    3031
    3132==== First week of the month: ====
    32 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: 
     33We 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:
    3334
    3435 * an owner
     
    5152 * It fixes a regression.
    5253 * It is a volunteer patch that doesn't seem destabiliizing to merge.
    53  * It fixes a pre-existing significant bug. (Where "bug" and "significant" are narrowly construed.) 
     54 * It fixes a pre-existing significant bug. (Where "bug" and "significant" are narrowly construed.)
    5455 * 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.]
    5556
     
    5859----
    5960== Prioritization for 029 ==
    60 Prioritization will change for each release, for this one we are guiding ourselves by the tasks associated to the deliverables we must complete for the contracts ending on Q3 2016. Then the other sponsor related work, then non-sponsor work. 
     61Each release we will decide on what should guide us while deciding how to prioritize our work.
     62
     63For 029we 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.
     64
     65Then the other sponsor related work, then non-sponsor work.
    6166
    6267(IMPORTANT BUGS OR SECURITY ISSUES TICKETS WILL GAIN PRIORITY OVER THINGS DEPENDING ON THEIR URGENCY)
    6368
    6469=== SponsorU Deliverables ===
    65 ===  ===
    66 Implementation of improved guard node design (y1 carry on deliverable) / Query for tickets marked as sponsorU -can and -must plus keyword tor-guard plus milestone 0.2.9.x-final
     70==== ''Guard node improvements (task 4.1)'' ====
     71 * ''An  implementation of our improved guard node design, included in our  codebase, with improvements as found necessary during research.''
     72   * [https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~tor-guards-revamp&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&col=points&col=reviewer&col=sponsor&order=priority tor-guards-revamp]. (I suggest we don't use"tor-guard" for this, since that is for every single guard-related thing.)
     73 * ''Improvements to the testing of our route selection infrastructure. Risks and contingencies for guard redesign.''
     74   * [https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~tor-route-testing&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&col=points&col=reviewer&col=sponsor&order=priority tor-route-testing]
    6775
    68 Improved testing of route selection infrastructure.
     76==== ''Improved public identity keys for Tor relays (task 4.2)'' ====
     77 * ''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).''
     78   * [https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~tor-ed25519-proto&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&col=points&col=reviewer&col=sponsor&order=priority tor-ed25519-proto]
    6979
    70 ===  ===
    71 === Implementation of improved guard node design (y1 carry on deliverable) ===
    72 === SponsorS Deliverables ===
     80==== ''Better DoS resistance throughout the Tor protocol (task 4.3)'' ====
     81''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.''
     82   * [https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~++++tor-dos-designs&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&col=points&col=reviewer&col=sponsor&order=priority tor-dos-designs]
     83 * ''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.''
     84   * [https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~tor-dos&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&col=points&col=reviewer&col=sponsor&order=priority tor-dos]
     85
     86==== ''Rigorous developer documentation (task 4.4)'' ====
     87 * ''A user’s manual for the compatibility and cryptographic layers at the bottom of the Tor code stack.''
     88   * [https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~tor-doc-lowlevel&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&col=points&col=reviewer&col=sponsor&order=priority tor-doc-lowlevel]
     89 * ''A  detailed high- and low-level overview of all modules in Tor, their data  flows, their intended interactions, and their actual behaviors.''
     90   * [https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~tor-doc-modules&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&col=points&col=reviewer&col=sponsor&order=priority tor-doc-modules]
     91
     92[[BR]]=== SponsorS Deliverables ===
     93==== Pluggable Transports: ====
     94==== Core Tor: ====
     95'' "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."''
     96
     97 * If we're doing all of these together, we should call it:
     98   *  tor-testing-integration
     99 * We could also split this into:
     100   * 1a + 1c. tor-chutney-usability
     101   * 1b. tor-tests-network
     102
     103''"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."''
     104
     105 * 2. tor-tests-coverage
     106 * 2a. tor-tests-unit
     107 * 2b. tor-client-scripting
     108 * 2c. tor-tests-stem
     109
     110''"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."''
     111
     112 * 3a. tor-controller-extension
     113 * 3b. tor-modularity
     114
    73115----
    74 == Team Capacity  ==
     116== Team Capacity ==
    75117How much the team can actually do.
    76118
     
    82124
    83125 * '''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
    84  * '''medium''' == 1 week or 3 days of work 
     126 * '''medium''' == 1 week or 3 days of work
    85127 * '''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)
    86128
     
    93135Are permissions of some kind the answer?
    94136
    95 Nick says "yes", so long as: 
     137Nick says "yes", so long as:
    96138
    97139 * There's some way to get external/unplanned patches merged.