There are a shell script and a batch file in the archive from which you can
run the demo. What you’ll see are three paths through the Bug Dialog, one
where we want bug reports from your version of VASSAL, one where we don’t
want bug reports, and one where the bug report check fails.
Comments welcome. I’d like to include this in beta4 (without the last pane,
since that’s not finished) if there are no objections.
A: The bug script checks against reported bugs on server so as not to
duplicate another report of the same thing
B: Its not an engine bug but something else like module problem
Either reason shouldnt the message specify why so users have a direction
where to go after / what to do if its a:) to simply see the progress of the
already reported bug or b: contact relevant party that needs to know (module
But now you got me thinking! You said the script is not checking against reported bugs on the server. Wouldnt you want to (if it is possible) so as to prevent a flood of bug duplication - Im guessing this is a big if? And if you were able to do that, would you then not want to enable reporting of previous versions of the engine so that a bug that may have never been encountered (nor fixed with later engine version) can still be reported?
We had the most duplicates during beta3 that I expect we’ll ever have,
due to catching a lot of old, previously-unknown bugs. I handled most
of the duplicates, by hand. It wasn’t that bad. If we have fewer than
20 bug reported per day, I can handle it myself using SF’s bug tracker.
I could handle more in the same time with Bugzilla. We never reached
that level of reports with beta3.
Also, there’s sometimes useful information in duplicates. E.g., there
were a number of bug reports where the first instance had no contact
information or description, but subsequent “duplicates” did.
I’m still not convinced that we can do anything reliable w/r/t
automating duplicate checking, since it’s possible for two different
bugs to generate stack traces which have the same last line, and also
possible for the one bug to generate two stack traces which don’t.