Backports Process

This is a draft policy describing what we do right now.

See the release policy for how we schedule maintenance releases.

Standard Workflow

Here's how the process works right now:

  1. 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
  2. when the ticket is merge_ready, it gets merged into the alpha and master branches
  3. the ticket is kept in merge_ready, but moved to the latest backport release milestone.
  4. when a ticket gets backported to a particular release, it is moved to the milestone for the latest remaining release
  5. once a ticket has been backported to all releases, it is closed as fixed

Current Status

The current status of potential backports is listed on teor's user page:

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.

Immediate Backports

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:

  • consider-backport-after-authority-test
    • 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:

  1. 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"

Unsupported Releases

When we stop supporting a release:

  1. 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"
  2. we move tickets that can be backported to an earlier release into the relevant milestone
  3. we close tickets that can't be backported any further
Last modified 9 months ago Last modified on Feb 3, 2020, 5:36:23 AM