Hi all,
The following approach builds on the idea of providing OS version from
information inside of OpenOCD, which resulted from the platform survey
thread. That idea should be more meaningful, when you reconsider the
ideas for automated testing report generation:
openocd -f bug_report.cfg \
-f interface/X.cfg -f board/Y.cfg \
-f optional_buggy_script.cfg \
-c 'bug report'
A hypothetical 'bug_report.cfg' script might contain the following:
debug_level 3
bug transport file # configures for the following commands
bug file path 'foo.log' # write to 'foo.bug' (or 'openocd.bug'?)
bug transport http # configures for the following commands
bug http method 'POST' # send report using HTTP POST
bug http url '...' # ... to the given URL
bug start # turns on special handlers, etc.
On the command line, the final 'bug report' would finish logging the
bug, writing or sending all output, errors, and other information (e.g.
extra configuration files provided on the command line, etc.) through
the proper transports. This call would also make the required OS calls
to get complete platform version information, so the user reports always
contain complete and correct information; this can be extended to report
the versions of all critical shared libraries as well. Heck, we should
include that information as part of the --version string too.
Distributors could patch bugreport.cfg to redirect bug reports to their
own support channels, if desired. Thusly, OpenOCD's Jim support makes
it possible for the final 'bug report' invocation to be customized
trivially: to file, e-mail, HTTP, or any other place imaginable.
Returning to version reports and usages statistics, I bet people would
be willing (and able) to run this command, because they will see it in
the package distribution. Survey results may still be interesting, but
this is the right way to measure future project vitality. My previous
ideas in this area required scripts in the source tree, but I think this
would be better -- these mechanisms get delivered with the binaries.
Will there be community support for this kind of work? Automatic bug
reports? Does anyone think the file transport may be easy to do and
want to take a stab at a prototype of it? Zylin's ZY1000 has a web
interface to do something very similar to this, so maybe they can donate
some of that code to be reused in this way....
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
