Subversion Issue Tracker

Issue Tracker Guidelines

As Subversion continues to mature, and as it gains attention from new users, folks will inevitably find bugs in, or come up with enhancements that they would like to see made to, the software. The Subversion community welcomes such requests for enhancements and reports of bugs. However, we ask that you follow a few guidelines with respect to the issue filing process.

Before filing an issue in the Issue Tracker, please:

When mailing the development 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.

After mailing the development list, you should expect your concern to be addressed with relative immediacy. That is, within a few days, you should get feedback on your mail. If indeed you have found a new bug in Subversion, or if your enhancement request is feasible, you will likely be asked to return here and file a new issue in the Issue Tracker.

What the Fields Mean

When an issue is first filed, it automatically goes in the "---" milestone, meaning it is unscheduled. 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 0.28. (Or they may put it the Post-1.0 or no milestone milestones, if they consider it tolerable in Subversion 1.0.)

If it goes into a pre-1.0 milestone, it is usually also assigned to someone (but please always check with a developer before assigning an issue to them). Also, remember that an issue filed in Post-1.0 can still be fixed before the 1.0 release, if some committer decides they want to -- "Post-1.0" merely means that we wouldn't block the release on that issue.

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

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.