Bug 317884

Actually, it seems that DrKonqi didn't report the second bug at all. In any case, I can't find it any more in the bug tracker.

By a simple search, I guess you are talking about what happens in bug 317883?  Or at least give one concrete bug number.

If so, then I do not see bug here: First you created bug 317883(for the kontact crash), then you somehow told (another) drkonqi the second crash (for plasma-desktop) should be added onto bug 317883 instead of creating another report.  Wasn't that ?

OK, I see, the two DrKonqis put the both bug reports into the same bug at bug 317883.
The bug that I am reporting here (bug 317884) is that two DrKonqi bug report windows (that popped up very shortly after each other) have shared the bug number. Twice I went through the process of describing the bug, looking at duplicates, and submitting the bug. (Because there were two crash traces etc.) This should result in two independent bug reports, irrespective of the fact that the two windows with the Crash information had popped up at more or less the same time.
Instead, what happened seems to be:
1. First DrKonqi pops up and figures out which number to use for the bug report. (317883)
2. Second DrKonqi pops up and figures out which number to use for the bug report (317883)
3. I click through one of the DrKonqis to report the bug. It reports to me that the bug was reported as 317883.
4. I click through the other DrKonqi to report the second bug. It reports to me that the bug was reported as 317883. (But it does not tell me that it reused an existing bug report for that.)

In my view, the bug is in step 2. The second DrKonqi should not pick the same bug number as the first DrKonqi, because then it cannot report a second bug that's independent of the first bug.

The bug number should be generated at the end of the submission step, just before submitting it, and the correct bug number should be shown on the final "Summary screen".

(My understanding of the steps may be wrong, but what happened is that the second DrKonqi window wrote into the same bug report, when it should have created its own bug report the way every DrKonqi does. Unless the user identifies it as the same bug during the submission. Here I may have said that it's "related to bug 317883", but I definitely did not identify it as a duplicate.)

Well, I know the problem that you try to describle in this report :) I just don't believe it happpens due to drkonqi itself, thus comment #1.
    
You seem to have some misundersstanding of how drkonqi works, probably influenced by the fact that two drkonqi show up almost at the same time. So I will try to explain why I don't believe it's drkonqi's fault.

First, each drkonqi window run in its own process, so the two drkonqi windows in your case are totally independent. They are unaware of each other.

Second, drkonqi, just like human being users, doesn't know the number for the new report before submitting the information. it is told, also like human being users, by the bugzilla server only after the information is submitted. Adding informatin to existing report is anthing, see next point.

Third, drkonqi by default always creates new report, unless user explictly tells it "this looks quite like the existing bug 123456, so adding information to bug 12345 instead of creating a new report." in the "Looking for possible duplicates" stage. And how does uses tell drkonqi the crash informatin should be appened to bug number 123456 ?  Two ways:

    a). drkonqi will ask bugzilla server to search for possible duplcates based upon backtrace ,  then bugzilla server will sent back those possible duplicates and drkonqi presents them to users and allow them to read, compare and confirm. Again, those numbers are given by the bugzilla server and drkonqi will happily append crash information to one existing report that users has chosen and confirmed as duplicate. Since the two crash backtrace quite unrelated , I really doubt this is what have happened.

    b). there is one "Manually enter a bug report id" in the duplicates finding stage. You can manually enter any existing bug number (like 123456 or 317883), and drkonqi will happily append crash information to that report. Actually, this is what I think you have done, see comment #1.  You entered 317883, so the second drkonqi happily did its due work. But I might be wrong.  


So, let's go through the suspected procedure

> 1. First DrKonqi pops up and figures out which number to use for the bug report. (317883)
it just can't figure out that number. It is told by the server only after the new report has been created.

> 2. Second DrKonqi pops up and figures out which number to use for the bug report (317883)
same as the first drkonqi. 


> 3. I click through one of the DrKonqis to report the bug. It reports to me that the bug was reported as 317883.
OK, that number 317883 is sent back by bugzilla server to the first drkonqi.  And the second drkonqi knows nothing about that number by itself..


> 4. I click through the other DrKonqi to report the second bug. It reports to me that the bug was reported as 317883. (But it does not tell me that it reused an existing bug report for that.)

As I have said above, drkonqi always creates new report unless users tell it not to.  I can only think of two explanation for how the thing happend :

    a). you didn't do anything special(meaning drkonqi should create new report), then drkonqi sent crash informatin and asked bugzilla server to create a new report, but bugzilla server didn't create a new report.  The server added the information to some existing report and sent that existing number back. All the fault went to the misbehaviing bugzilla server. Quite unlikely.

    a). you somehow clicked that "Manually enter a bug report ID" entry, entered 317883, and eventually told drkonqi to append information to that report.  Drkonqi did its job as told. Not its fault.


> (My understanding of the steps may be wrong, but what happened is that the second DrKonqi window wrote into the same bug report, when it should have created its own bug report the way every DrKonqi does. Unless the user identifies it as the same bug during the submission. Here I may have said that it's "related to bug 317883", but I definitely did not identify it as a duplicate.)

That sentence "the report of that is under bug 317883." in the comment part will not make influence .  It won't accidentally trick drkonqi. The decision of creating or appending is done before that stage.

Dear Jekyll! Thank you for such a detailed analysis!

I can't remember if I entered the bug number for the other report explicitly as a bug number. I probably thought about it so that I can say "This may be related to bug ...". But I don't think I told DrKonqi to mark the bug as identical, so I don't think it should have placed the information in the same bug report.

In any case, at the bottom of the second report, it says as follows. Wouldn't DrKonqi write there something like "User indicates that this is the same bug as ...", if I had indicated that?

This bug may be a duplicate of or related to bug 241562.

Possible duplicates by query: bug 264250, bug 263419.

Reported using DrKonqi

> Wouldn't DrKonqi write there something like "User indicates that this is the same bug as ...", if I had indicated that? .

That doens't sound like a bad idea. I will consider that

Git commit 3a80d305d3786f6362afe617bdc26ab71410b865 by Jekyll Wu.
Committed on 22/07/2013 at 03:19.
Pushed by jekyllwu into branch 'master'.

Make it clear what possible duplicates are indicated by the reporter.

M  +1    -1    drkonqi/reportinterface.cpp

http://commits.kde.org/kde-runtime/3a80d305d3786f6362afe617bdc26ab71410b865

Sorry for the slow action. 

Close this report now, since I really don't think there is other thing to do for this mysterious and non-reproducible problem.