How Tor uses trac tickets

This page describes how we use Trac tickets for the little-t Tor software (Core Tor/Tor). Other components can decide that they want to follow the same process, or do something else.


This is critical. We use these milestones:

  • Tor 0.x.y.z-final For tickets that we want to merge into the 0.x.y.z series. If 0.x.y.z is in alpha, this includes stuff under active development. If 0.x.y.z is stable, this should only include backports.
  • Tor: Unspecified For tickets that we would like to do quite soon, given infinite knowledge and resources. For most of these tickets, we could merge a good patch into the current development branch if somebody writes one. We might do one ourselves some day.
  • Tor: Very Long Term For tickets that will require deep architectural changes to Tor that we don't understand well enough to plan when we might make them; for tickets of uncertain benefit and great difficulty; for tickets we've got no plans to do any time soon for some other reason.


Once in a while, we'll do a triage for a specific milestone. If a ticket is triaged out, this keyword will be added to it:

  • triage-out-{series}-{date} Where series is the version of the milestone that the ticket is being removed from (ex: 030). date is the year and month of when the triage occurred with format YYYYMM


This is a free-form field, so use any extra keywords that you think will be helpful. Commonly used ones are:

  • {username}-patch The user called username on trac wrote this patch. Mainly, we use this for developers who write a lot of patches, so that it's easy to say "show me everything where I wrote the patch here" or "show me everything in needs_review where I didn't write the patch."
  • Tor subsystems. Describes the parts of Tor most affected by this ticket.
    • tor-client: Client functionalities.
    • tor-relay: Everything related to being a relay.
    • tor-hs: Hidden/Onion service.
    • tor-dirauth: Directory authority.
    • tor-pt: Pluggable Transport.
    • tor-guard: Everything related to Guard code.
    • tor-bridge: Bridge
    • tor-sr: Shared random.
    • tor-doc: Everything related to documentation (comments, man page, doc/; previously just doc?)
    • tor-control: Anything related to the control port.
    • tor-sandbox: Related to sandboxing of "tor".
    • tor-crypto: Crypto subsystem.
    • tor-dns: Anything related to DNS subsystem or resolving address.
    • tor-sched: Scheduler related (usually in scheduler.c and cie).
  • Ease-of-task keywords
    • "points <= .1" (not a keyword): it will take less than an hour, if you know how.
    • easy: it wouldn't be very hard for a developer with no previous Tor experience
    • intro: it's a good introduction to the tor codebase, but it might not be so easy (e.g., might touch a lot of things in a not-too-complicated way).
    • term-project: it's a good subject for an undergraduate term project or a GSoC student.
    • research-program: it's a good topic for several papers, or a dissertation, or something like that.
  • Security keywords:
    • sec-dos: Denial of Service
    • sec-hardening:
    • sec-trove: Ticket associated with a TROVE
    • sec-<whatever> (let's try to list the one we want)
  • Rust keywords:
    • rust-pilot: Tasks before we determine if Rust can be a first-class language in tor
    • rust: tor-related tickets requiring rust knowledge
  • Specification (and proposal) keywords:
    • tor-spec About bugs or changes in the specifications (tor-spec.git, etc.; previously just spec?)
    • propXXX: This ticket implements (part of) proposal XXX
    • needs-proposal: The work of the ticket needs a proposal.
  • Testing keywords: (WIP)
    • test
    • test-coverage
    • test-fuzzing
    • test-unit
    • test-integration
  • What this ticket is about?
    • regression: This ticket is a possible regression.
    • refactor: This ticket is about refactoring some Tor code.
    • performance
  • Planning keywords:
    • maybe we should have some way to indicate "this is deferrable", "this is in", "this is out" as we do triage... but they should not stick around forever.
    • {series}-deferrable This ticket can be safely deferred from series, though it would be nice to do. (Series here or elsewhere is a version number without periods or final number, such as "025" or "026".)
    • {series}-backport: where series is the version eg. 030-backport.
    • lorax: There is no plan to fix this, but we'd be happy to take a good patch for it if someone else cares enough to write one. ("Unless someone like you cares a whole awful lot / Nothing is going to get better. It's not!" -Dr. Seuss, The Lorax)


We don't have a consistent way to set this. I would prefer that we get one some time.


This is more or less meaningless as we use it.


This can be the version in which a bug first occurred, but more typically it is the version in which the bug was noticed.


Is Core Tor/Tor.

Last modified 3 days ago Last modified on Sep 18, 2017, 5:51:08 PM