Version 1 (modified by isabela, 4 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

.Release schedule

  • New stable release happens every 6 months
  • Next stable release date is: October 1st
  • Next Freeze date is: September 1st
  • Alphra 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

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. 


SponsorU Deliverables

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

Improved testing of route selection infrastructure.

Implementation of improved guard node design (y1 carry on deliverable)

SponsorS 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