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

Apr 8, 2016, 1:40:10 AM (5 years ago)



  • org/teams/NetworkTeam/ReleaseGuidelines

    v1 v1  
     1= '''Set of guidelines for releasing Core Tor 0.2.9 ''' =
     2The  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 ==
     5 * New stable release happens every 6 months
     6 * Next stable release date is: October 1st
     7 * Next Freeze date is: September 1st
     8 * Alphra releases happens every month (???)
     9 * Triage for next release (0.3.0) - starts on freeze date of previous release (Sept 1st)
     11=== '''Open questions''' ===
     12'''Should we split "0.2.9.x-final" into:''' * 0.2.9.x-release
     14 * 0.2.9.x-maint   ?
     15 * ''Nick says yes.''
     17'''Should we be working on stuff for the next release while one release is in -rc?'''
     19 * ''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 * ''Nick thinks that reviewing and fixing leftover tickets should get done early, and should get some priority.''
     26== Team Routines: ==
     27===  ===
     28=== Each month ===
     29'''We plan our work in a monthly basis using the tag: '''    TorCoreTeamYYYYMM
     31==== First week of the month: ====
     32We 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:
     34 * an owner
     35 * a reviewer
     36 * estimation points (small, medium, large)
     38==== Last week of the month: ====
     39We 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
     41 * start building an alpha release for the month (?????)
     42 * move open, or in review tickets to the next month tag
     44=== Each week ===
     45We will look at a query of the monthly tag TorCoreTeamYYYYMM
     47Make sure nothing is waiting for review without a reviewer assigned to it.
     49We'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:
     51 * It fixes a regression.
     52 * 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 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.]
     56If  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
     59== Prioritization for 029 ==
     60Prioritization 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. 
     64=== SponsorU Deliverables ===
     65===  ===
     66Implementation 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
     68Improved testing of route selection infrastructure.
     70===  ===
     71=== Implementation of improved guard node design (y1 carry on deliverable) ===
     72=== SponsorS Deliverables ===
     74== Team Capacity  ==
     75How much the team can actually do.
     77'''Out of 5 days in a week how many do we actually code?'''
     79If  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.
     81Based on that we are using the following values for ticket's points:
     83 * '''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
     85 * '''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)
     88== Making triage stick ==
     89Nick  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.
     91If  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.
     93Are permissions of some kind the answer?
     95Nick says "yes", so long as:
     97 * There's some way to get external/unplanned patches merged.
     98 * Surprise bugs can get fixed.
     99 * We do this as discussion not dictatorship.
     100 * We revisit periodically.
     101 * We can meet other teams' needs.
     102 * We can add subtickets as we discover unexpected prerequisites