Backports Process

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

See the release policy for how we schedule releases, and decide which tickets to backport.

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 backports is:

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

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.

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 4 days ago Last modified on Oct 18, 2019, 1:32:08 AM