Looking at the top 25 bugs: 11 are in custom code (including VASL/CASL) and account for more than 50% of the bug occurrences in the list and all the errors which have occurred in the last 7 days. The worst of the remaining bugs seems to be mainly triggered by VASL and probably relates to problems finding the correct boards.
So the state of the basic Vassal code is actually quite good. The problem is that the developers only see the bug reports and not the successful runs of Vassal and this can be quite negative.
Perhaps the launcher should send a small packet when it exits saying how many modules were launched so we can see the successes as well as the failures (and see how large a group the users of Vassal are)
Looking at the top 25 bugs: 11 are in custom code (including VASL/CASL)
and account for more than 50% of the bug occurrences in the list and all
the errors which have occurred in the last 7 days. The worst of the
remaining bugs seems to be mainly triggered by VASL and probably relates
to problems finding the correct boards.
I would only go so far as to say that many of these bugs have stack
traces which end in VASL code. I suspect that 2376, 2798, and 2615
are all threading problems; the cause need not be in the VASL code
for stack traces to end there. I think it’s more likely that the
problems are in VASL than in VASSAL, but it also wouldn’t be so
surprising if VASL excercised some code paths in VASSAL that aren’t
used much elsewhere.
So the state of the basic Vassal code is actually quite good. The
problem is that the developers only see the bug reports and not the
successful runs of Vassal and this can be quite negative.
The distribution of bug reports has a long tail. There are presently
276 bugs in the tracker. And it’s not only the bug reports—most of
which are due to uncaught exceptions—that led me to conclude that the
code is in a bad state. A lot of our code is so tangly that it’s not
testable, which means that it’s unnecessarily difficult to modify and
to have have any assurance that your modifications work and don’t break
other, seemingly unrelated things.
Perhaps the launcher should send a small packet when it exits saying how
many modules were launched so we can see the successes as well as the
failures (and see how large a group the users of Vassal are)
We could do this. It would also be useful to collect OS and architecture
information at the same time, so we had a better idea of what people are
using. (E.g., as soon as the 32-bit machines are dead, it would be nice
to know that.) But it also has to be something that the user can turn
off. I don’t like the idea of software phoning home without the user’s
consent.
Perhaps like Netbeans Ide ask if you can collect stats during installation. Also could make a global preference so users can turn on/off.
Knowledge of how many use server or just pbem, which modules are used etc would be very interesting and also give idea how big a userbase vassal has.