On Mon, 8 Oct 2007, Dirk Mueller wrote: >> 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?
#ifdefs are a bad idea, IMO. The other two guidelines are possibilities. There won't be a hard-and-fast rule. For example, I think Bart wants/needs some minor changes for DRD. These seem pretty reasonable, and they would improve DRD's messages, and they're not likely to screw anything else up, so they're fine. Stephen's Fjalar changes (mostly to do with better debug info reading, IIUC) are much larger, and so less likely to be accepted, although if they are generally useful they could be. They would certainly require more scrutiny. Perhaps they could live in a branch for a while. In general, small changes are more likely to be acceptable than large changes, and general features are more likely to be acceptable than features that are more tool-specific. >>> 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? No, but it's a possibility, and the "exp-" prefix is an attempt to avoid it. > If not so, why treat those experimental plugins as a second class citizen? Because they are second class citizens -- they haven't been widely used. Once they have been, if they seem good enough, the can be promoted to non-exp status. Dirk, just to clarify -- you've asked lots of questions about the details, which is good. But do you think it's a good idea in general? We have approvals from Bart and Stephen, and an implicit approval from Robert. Nick ------------------------------------------------------------------------- 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
