Subversion Issue Tracker

Issue Tracker Guidelines

We use the "Buddy System" for filing issues.
Before filing a new issue, please:

  • Re-read the documentation
    (especially the FAQ and the online Subversion book).

  • Look through all existing issues, or search their summaries:

    to see if this bug has already been reported.

  • Find someone else who agrees this is a bug.
    Post to the users@subversion.tigris.org mailing list (or to dev@subversion.tigris.org if you're already pretty sure it's a bug), or chat in IRC, regarding the bug or feature request you were about to file. People there will ask you questions, try to reproduce the problem, advise you if there's any past history of similar problems, and in general help you decide whether a new issue is warranted. If it is, they can also help you get the bug report into a useful form. See here for how to write a useful bug report.

    If you do file an issue, remember to include a link to the mailing list message(s) or IRC conversation where you discussed the problem. Not only does this provide important context for anyone reading the issue, it also confirms that the issue has passed the basic buddy test: you found someone else who agrees it's a problem. Issues that haven't been through the "buddy system" may be summarily closed. We're sorry to do this, but statistically, most unbuddied filings turn out to be bogus, and the issue tracker is not a convenient place to separate the good reports from the bad.

We depend on the mailing list and IRC channel as a first level of filtering for our bug tracker. Without this filtering, the tracker would be full of duplicate issues, non-issues, and unreproducible issues. Please help us keep the bug database clean, by always finding a buddy before you file!

When mailing the list with a concern, make sure that your e-mail describes your bug or enhancement fully. Provide details about the versions of the relevant software (Subversion, Apache, neon, etc.) that you are using, about your operating system, and about any other thing that might seem pertinent to the issue. If you can provide a script which consistently reproduces a problem, that can be incredibly helpful to those evaluating and/or working on your issue.

Filing New Issues, Modifying Existing Issues

You must be logged in to the web site to add a new issue, or comment on existing issues. To modify aspects of issues other than simply leaving a comment (i.e., to change fields or status), you must be logged in, and possess the Observer role in the Subversion project — even for issues that you created yourself.

Here's how to acquire the Observer role:

  1. Log in on the tigris.org site
  2. Go to the Subversion project front page
  3. Click on the Request project role link directly below the "Project Home" line
  4. Request the Observer role
  5. Wait for the confirmation e-mail (almost always will be completed within 24 hours)

What the Issue Fields Mean

When an issue is first filed, it automatically goes in the "---" target milestone, which indicates that the issue has not yet been processed. A developer will examine it and maybe talk to other developers, then estimate the bug's severity, the effort required to fix it, and schedule it in a numbered milestone, for example 1.1. (Or they may put it the unscheduled or nonblocking milestone, if they consider it tolerable for all currently planned releases.)

An issue filed in unscheduled might still get fixed soon, if some committer decides they want it done. Putting it in unscheduled merely means it hasn't been scheduled for any particular release yet. The nonblocking milestone, on the other hand, means that we do not anticipate ever scheduling the issue for a particular release. This also does not mean the issue will never be fixed; it merely means that we don't plan to block any release on it.

Severity is represented in the Priority field. Here is how priority numbers map to severity:

  • P1: Prevents work from getting done, causes data loss, or BFI ("Bad First Impression").
  • P2: Workaround required to get stuff done.
  • P3: Like P2, but rarely encountered in normal usage.
  • P4: Developer concern only, API stability or cleanliness issue.
  • P5: Nice to fix, but in a pinch we could live with it.

Effort Required is represented in the Status Whiteboard with an "e number", which is the average of the most optimistic and most pessimistic projections for number of engineer/days needed to fix the bug. The e number always comes first, so we can sort on the field, but we include the actual spread after it, so we know when we're dealing with a wide range. For example "e2.5 (2 / 3)" is not quite the same as "e2.5 (1 / 4)"!

Enter the Issue Tracker

And so, with further ado, we give you (drumroll…) the Subversion Issue Tracker.

Again, remember that to add or modify issues, you must be logged into the website.