On Monday 08 October 2007, Nicholas Nethercote wrote: > > 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?
General comment. Although anything that makes this situation better would be highly welcome. > Tools that required big core changes would be less likely to be accepted, > although it would be decided on a case-by-case basis. how do you think should this look like? accept core changes in an #ifdef? accept core changes as long as they can not affect any of the non-experimental tools? Delay addition of an experimental plugin until it doesn't require core changes? > > what about documentation that is written with the exp- prefix, which then > > becomes out of date? broken user habits/custom scripts? > That doesn't worry me particularly. We've broken backward compatibility in > the past on such things. Also, the possibility of a future name change > would be made clear in the documentation on experimental tools, so there'd > be an inherent "user beware" aspect to them. Did you observe at all that someone questions valgrind's (memcheck/core) reputation because they found a bad plugin somewhere? If not so, why treat those experimental plugins as a second class citizen? > I also don't think most of > them would be particularly widely used -- Memcheck accounts for over 80% of > Valgrind usage. Thats true, but I thought one of the aspects of this proposal was to change that :) > Some extra information that might be of interest: at one point Julian and > I were considering having two versions of the distribution, "valgrind" and > "valgrind+extras", due to concerns that if the experimental tools were of a > lower quality that they might hurt Valgrind's reputation. Ok. If the other option is to do two branches (stable and experimental) in addition to the already stable and development code branches, then I'm all against avoiding yet another level of indirection/diversity. Greetings, Dirk ------------------------------------------------------------------------- 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
