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

Apr 11, 2016, 2:54:48 PM (4 years ago)



  • org/teams/NetworkTeam/ReleaseGuidelines

    v1 v2  
    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
    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.''
    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?'''
    1921 * ''Nick suggests that everybody assume they will be on bugfix during -rc time.''
    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?'''
    2325 * ''Nick thinks that reviewing and fixing leftover tickets should get done early, and should get some priority.''
    2628== Team Routines: ==
    27 ===  ===
    2829=== Each month ===
    2930'''We plan our work in a monthly basis using the tag: '''    TorCoreTeamYYYYMM
    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:
    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.]
    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.
     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.
     65Then the other sponsor related work, then non-sponsor work.
    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   * [ 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   * [ tor-route-testing]
    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   * [ tor-ed25519-proto]
    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   * [ 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   * [ tor-dos]
     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   * [ 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   * [ tor-doc-modules]
     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."''
     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
     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."''
     105 * 2. tor-tests-coverage
     106 * 2a. tor-tests-unit
     107 * 2b. tor-client-scripting
     108 * 2c. tor-tests-stem
     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."''
     112 * 3a. tor-controller-extension
     113 * 3b. tor-modularity
    74 == Team Capacity  ==
     116== Team Capacity ==
    75117How much the team can actually do.
    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)
    93135Are permissions of some kind the answer?
    95 Nick says "yes", so long as: 
     137Nick says "yes", so long as:
    97139 * There's some way to get external/unplanned patches merged.