11 comments
Comment actions Permalink

Maxim Shafirov wrote:

>Just an observation. Request 13480 has 26 (sic!) dupes.
>

This feature
http://www.intellij.net/tracker/itn/viewSCR?publicId=605
would surely help.

Alain

0
Comment actions Permalink

i can't wait to get the next build that this is fixed in.

0
Comment actions Permalink

Well, not to start a flame war, or blame someone, or anything, but the
longer the release cycles (which means a longer delay between a frequently
hit bug and its fix) the harder it is to try to stay up to date with all the
reported bugs. There are 161 fixed bugs in versions > 833 and tons of filled
in reports (276 reported only for 833).

At this point one has two options: either ignore any problems hoping someone
else reported them and a fix is coming in the next build (that's what I end
up doing after about a week, I just assume that most bugs would be hit in
that timeframe), or fill in a bug report. Searching through all those
reported bugs is too time consuming to be done during worktime (when most of
the bugs are detected). Not to say I don't try to do it, just why I see it
not being done all the time.

I guess the automatic reporting tool could take care of this issue.

Just my 2 cents,
Andrei

"Maxim Shafirov" <max@intellij.net> wrote in message
news:be3ukh$l9$1@is.intellij.net...

Just an observation. Request
http://www.intellij.net/tracker/idea/viewSCR?publicId=13480 has 26 (sic!)
dupes.

>

--

>

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"

>
>
>


0
Comment actions Permalink

i agree with you. Jetbrains said they will give us a build as soon as it passes 50% or more of the tests. So while it's hard for us to keep up we certainly don't want a build that isn't even half right :)

0
Comment actions Permalink

It's hard to locate similar stacktraces when they can occur at even location.

Even if they are the same, the person will not know whether it's the same because the description seems to imply different ... and we are not familiar with the internals.

0
Comment actions Permalink

Maxim Shafirov wrote:

Just an observation. Request
http://www.intellij.net/tracker/idea/viewSCR?publicId=13480 has 26 (sic!)
dupes.


When I search for existing reports I generally don't copy/paste a search
string. I search for a small but relevant part of the stack trace, such
as "d.z.resolve", and I type this manually because that's faster for me.

It took me a while to realize that the quick find box in the bug browser
only searches for complete words, and that I have to search for
"com.intellij.psi.impl.d.z.resolve" in order to get any matches. Back
when I had to use the full search page, searching for Title&Description
CONTAINS d.z.resolve would get me the complete list of bugs.

But it's easy to think that if you search for "d.z.resolve" and there's
no match at all, then certainly there can't already be a stack trace
containing com.intellij.psi.impl.b.z.resolve(z.java:17) -- and so you
report a new bug.

Another problem is that package names don't stay constant. In 13249 the
stack trace visits com.intellij.psi.impl.source.e.b.b, but in 13643 it
visits com.intellij.psi.impl.source.c.b.b, for example. Several other
packages in those stack traces have also changed names, which makes it
more difficult to find matches.

0
Comment actions Permalink


I checked all the dupes and there are 3 stacktraces family that seems completely different. Here are some links
http://www.intellij.net/tracker/idea/viewSCR?publicId=13480
http://www.intellij.net/tracker/idea/viewSCR?publicId=13165
http://www.intellij.net/tracker/idea/viewSCR?publicId=13320
How could we know that those are the same bug ?

btw it's true that there are a lot a dupes ...

0
Comment actions Permalink

"Maxim Shafirov" <max@intellij.net> wrote in message
news:be3ukh$l9$1@is.intellij.net...

Just an observation. Request
http://www.intellij.net/tracker/idea/viewSCR?publicId=13480 has 26 (sic!)
dupes.


Some changes to the Tracker might help reduce dupes.

For example, if there were topics to which bugs and features could be
assigned, searching for dupes might be eaiser. A topic called "internal
errors" would be a lot easier to search through than the entire open bug
list.


Erik


0
Comment actions Permalink

Just out of curiousity, how do you all go about finding out if there are duplicates? are bugs assigned to individuals based on feature, and you all just "know"?

Or is there something that we could do to prevent this from occurring?

My own practices are to do a query with key words from my problem, and then scan down the titles. If nothing pops out, then I submit the request. Otherwise, I'll make a note of it in the previously open problem.

Unfortunately, I find that a lot of the titles are misleading.

Mike

0
Comment actions Permalink

Michael Kirby wrote:

My own practices .. scan down the titles.

>
When there is stacktrace, I also do a quick search - on the web - for a
few lines. I wished the ITN would do that for us.
There is hope in that direction :
http://www.intellij.net/tracker/itn/viewSCR?publicId=605

>Unfortunately, I find that a lot of the titles are misleading.
>
True. You look for 'copy' or 'paste', and people used 'pasting',
'Ctrl-C', or "return of bug 666".

Alain

0
Comment actions Permalink

Just out of curiousity, how do you all go about finding out if there are

duplicates? are bugs assigned to individuals based on feature, and you all
just "know"?

Request is assigned to a developer basing on the area of the request. If the
inital assignment was wrong it can be reassigned later. Normally 2 bugs
which are duplicates are assigned to the same developer and he's able to
find the duplication.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Michael Kirby" <kirby@ess.mc.xerox.com> wrote in message
news:18738782.1057596970658.JavaMail.itn@is.intellij.net...

Just out of curiousity, how do you all go about finding out if there are

duplicates? are bugs assigned to individuals based on feature, and you all
just "know"?
>

Or is there something that we could do to prevent this from occurring?

>

My own practices are to do a query with key words from my problem, and

then scan down the titles. If nothing pops out, then I submit the request.
Otherwise, I'll make a note of it in the previously open problem.
>

Unfortunately, I find that a lot of the titles are misleading.

>

Mike

>


0

Please sign in to leave a comment.