> > some of the experimental tools available require significant (and > > conflicting) changes to the core, which is the reason e.g. distributions > > have troubles packaging the addon experimental tools. > > Is that an argument for or against the proposal, or just a general comment? > > Tools that required big core changes would be less likely to be accepted, > although it would be decided on a case-by-case basis.
Yes, I'd want to be relatively conservative about changing the core. But my impression is that the core/tool interface is pretty effective at insulating tools from the core, and most tools will not need much by way of core changes. For those that do, we could put development on a branch so as to see what core changes will be necessary, then merge to trunk if they seem ok. > > Tagging valgrind assertions/crashdumps/warning output with a clear > > indication that an experimental plugin was run (sort of tainting-concept) > > seems more useful to me. > > We could do that in addition. In addition, yes. But not instead of the exp- name. For the most part tools which are under development don't crash; they just tend to produce results which are sometimes unreliable, inaccurate, etc. And so you want to make clear to users which tools are considered production-ready (you can rely on the output) and those which aren't (you have to be more careful in interpreting the output). J ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
