Child pages
  • Tracker

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

.NET Profiler Tracker is a place where you can submit bug reports or feature requests (we use the term "Software Correction Request" - SCR - to unify the two).

To login to the tracker, go to http://www.intellij.net/tracker/netprofiler/browse. Note that you will have to register in order to access it.
You are welcome to submit feature requests and bug reports, but please first read the instructions below.

How to submit an SCR

You need to remember the 3 simple rules:

  1. Please submit only one issue per request. It is extremely difficult to process composite requests, especially when different issues lay under responsibilities of different developers.
  2. If you have only a vague idea for a feature, please discuss it in .NET Profiler EAP newsgroup news://news.intellij.net/jetbrains.net.profiler.eap before submitting.
  3. Please try to search for duplicates before posting. Developers need enough time to actually fix bugs, don't they?

Ok? Thanks for understanding.

Now just click on 'Submit New Request'. You will be asked to specify:

Title: One-line description of a bug/feature. Try to make it short, but informative (we know, it is sometimes tricky). 'Bug in rename' is a bad idea. 'Renaming field creates conflict with local variable' is much better.

Description: Longer description of a bug/feature. If you submit a bug, try to provide as much info as possible. If you submit a feature, it is a good idea to suggest some use cases.

Type: Can be 'Feature', 'Bug', 'Cosmetics' or 'Exception'. The first two are obvious. 'Cosmetics' is some unpolishness: a typo, unaligned dialog layout or something of this sort. 'Exceptions' are normally submitted via our error reporter (see below).
Be aware that when your request is processed its type may change (e.g. you think that some functionality is missing, while it has been already designed and implemented, but it just does not work - and your feature request becomes a bug report).

Build: build on which a particular problem happens (mostly for bugs, of course)

OS: the OS you work on

You can also attach additional files to your request (screenshots or some test cases).

Having completed all that, you are done - just click the 'Submit' button.

What happens afterwards

After you submitted a request, it obtains a special state, namely Submitted. It means that the request has not been processed yet by the development team and awaits a decision on its further state.
When the request is processed it can be assigned one of the following states:

Open: we accept the request to be reasonable. You will see what version it is planned for (if any) and what priority is assigned to it.
Fixed: the request has been fixed/implemented. You will see the build number it is fixed in.
Duplicate: there is already a similar request. You will see its Id.

More Info Needed: we agree there is a problem, but we cannot reproduce it and we (usually desperately) need more additional info. If request is assigned such a state, we will often give you some hints as to what data might help us.
Not Repeatable: we cannot reproduce the problem. You will see the build number we have tried to reproduce it in. This usually means that either the problem was somehow fixed in course of other code changes, or we think there was just a mistake or misunderstanding.

To Be Discussed: we need to discuss whether and how this feature should be implemented, or whether this bug is really a bug. Everyone is welcome to participate in such discussions.
Do Not Fix: we are not going to implement this feature/this is not a bug. Usually we will post an explanation.

Obsolete: the request is no longer applicable. This usually happens when the corresponding functionality has been changed dramatically since request submission.
Problem: we accept the request to be reasonable, but do not see any possible way of fixing it. We will usually post a comment.

Discuss an SCR

Each tracker request has an associated discussion thread. You will recieve e-mail notifications when a message is posted to that thread, or important changes to the state of the request occur.
You can also start recieving such notifications for any particular request you are interested in, by clicking the "Watch this topic" hyperlink at the top of the dicussion thread. To stop recieving notifications click the "Stop Watching Topic" hyperlink.

About priorities

When we open a request, we usually assign some priority to it. Please note that requests are not neccessarily going to be fixed in priority order. We use priorities mainly for our internal planning, and they are subject to change in course of development.

Voting

Each EAP member has 100 votes that she can distribute across her favorite/most annoying requests. When the request is fixed the votes cast for it are returned back.

The voting lets you express your preferences and opinions in "quantative" manner and gives us a hint of what is important for our users, but it is by far not the main factor in our planning.

Exceptions

Since you are using the EAP version, .NET Profiler may sometimes produce the so called "Internal Errors" (which are actually exceptions that have not been caught, or assertions in code that turned out to be false). If this happens, ReSharper will suggest to automatically submit the problem into the tracker. This will generate a Submitted request with the type Exception. Sometimes it may turn out that someone else has already submitted this error. In this case no new SCR will be created, and only a comment will be added to the existing SCR.