⚠We should update this to describe our current process, and possibly merge it with our other merging/reviewing/etc gitlab checklists.
—nickm, 14 August 2020
This is a draft policy describing what we do right now.
See the release policy for how we schedule maintenance releases.
Here's how the process works right now:
- we mark tickets that might need a backport with tags like "035-backport"
- if we are unsure about a ticket, we tag it with "035-backport-maybe"
- previously, we used "035-backport?", but that's not visually distinct enough
- when the ticket is merge_ready, it gets merged into the alpha and master branches
- the ticket is kept in merge_ready, but moved to the latest backport release milestone.
- See the list of current releases
- when a ticket gets backported to a particular release, it is moved to the milestone for the latest remaining release
- once a ticket has been backported to all releases, it is closed as fixed
The current status of potential backports is listed on teor's user page: https://trac.torproject.org/projects/tor/wiki/user/teor#Backports
Deciding which Tickets to Backport
In general, we want to minimise backports.
All backports should be small fixes that are easy to review.
We backport these types of changes:
- essential documentation that has security or serious usability consequences
- fixes for serious usability issues
- medium or high security fixes, based on our security policy
- significant compatibility fixes for supported platforms
We never backport new features.
The following changes should be backported immediately after CI passes:
- CI fixes
- GeoIP file updates
- Fallback directory mirror updates
- Authority updates
- Urgent Patches, as documented in the Merge Policy
Waiting for Testing
We often want to say "wait until after this ticket has been tested in the next alpha before backporting it". I'm using tags like "consider-backport-after-0404-alpha" right now.
For higher-risk changes, we will wait for testing in the next stable release, then backport.
Waiting for Testing on an Authority
I'm also using the tag:
- lower-risk changes that affect authorities: these changes are usually tested by arma on moria
I'm happy to work out authority testing with an authority operator.
Waiting to see if a Backport is Needed
I'm using the tag:
- consider-backport-if-needed: Changes that may not be backported. Before we backport this change, we need to make sure that it doesn't cause any bugs in the next release, and that it actually fixes an important bug in previous releases.
Changes that are Not Backported
Here are the exceptional cases:
Deciding Not To Backport
If we decide not to backport a ticket to any of the possible remaining releases: A. we replace the backport tag with a tag like "035-no-backport"
- previously, we removed the backport tag, or used "035-backport-unreached", but that turns up in keyword searches for "035-backport"
When we stop supporting a release: A. we mark all tickets with a tag like "034-unreached-backport"
- previously, we used "034-backport-unreached", but that turns up in keyword searches for "034-backport" B. we move tickets that can be backported to an earlier release into the relevant milestone C. we close tickets that can't be backported any further