Opened 5 years ago

Last modified 17 months ago

#16570 new enhancement

Add new 'awaiting backport' state for Trac tickets?

Reported by: arma Owned by:
Priority: Medium Milestone:
Component: Internal Services/Service - trac Version:
Severity: Normal Keywords:
Cc: nickm, dgoulet, isabela, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


We have a pile of Tor-component tickets that are fixed but not closed. Many of them are in this state because of a tiny little keyword called 026-backport. Should we move all of these into a new awaiting-backport state so they're easier to distinguish?

Child Tickets

Change History (7)

comment:1 Changed 5 years ago by arma

Cc: nickm dgoulet isabela added

comment:2 Changed 5 years ago by qbi

Component: TracService - trac

Move all tickets from trac to "Service - trac" component.

comment:3 Changed 3 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:4 Changed 17 months ago by arma

Owner: erinn deleted
Status: newassigned

comment:5 Changed 17 months ago by arma

Cc: teor added
Status: assignednew

adding teor to the cc list since I believe they are considering how best to describe and track tickets that are awaiting backports.

comment:6 in reply to:  5 Changed 17 months ago by teor

Replying to arma:

adding teor to the cc list since I believe they are considering how best to describe and track tickets that are awaiting backports.

Here's how the process works right now:

  1. we mark tickets that might need a backport with tags like "035-backport"
  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. (Which is currently 0.3.5)
  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

Here are the exceptional cases:

When we stop supporting a release:

  1. we mark all tickets with a tag like "033-backport-unreached" (or "035-unreached-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

If we decide not to backport a ticket to any of the possible remaining releases:

  1. we remove the backport tags for the remaining releases
  2. I have been replacing it with a tag like "035-backport-unreached", but maybe that's confusing. I think we should use "035-no-backport"

I quite like this process and I feel no need to change it.

It's also relatively easy to write a ticket query that shows all backportable tickets:

What I would like is a way 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, but I'd really like to be able to hide new backports until they have been tested enough.

Here's are some filters we could use to hide tickets:

  • a particular release (when we add a particular version to the versions list in trac)
    • I don't know if Trac's query syntax supports filtering by the set of values in another field
  • a particular date (or a particular number of days in the future)
    • we'd need a new time field "backport", the query syntax would be ""
Note: See TracTickets for help on using tickets.