|
From: Josef W. <Jos...@gm...> - 2006-09-07 00:34:02
|
On Saturday 02 September 2006 03:34, Julian Seward wrote: > New tools for 3.3.0 > ~~~~~~~~~~~~~~~~~~~ > ... > The problem with experimental tools is they need a lot of engineering > effort to get them to a production status (or conclusion that the tool > cannot be moved to production status for technical reasons.) Getting > that effort means having users try them out and contribute feedback > and patches. Putting the tools in the tree, and having them compile, > even if they don't work well, makes it a lot easier for users to do > that. It's also more inclusive for the tool authors. > > There are downsides: > > - more code in the tree inevitably means a higher maintenance overhead > > - stability of the existing code base is important, and we don't want to > undermine that > > I'm thinking of an arrangement in which experimental tool authors have > commit access to the tree, but > > - we make it clear it is their responsibility to keep tools compiling > and working > > - we ask that such authors do not commit changes outside of their individual > tools without first consulting with the core developers I think it would be better for experimental tools to first live outside of VGs core code base; we should provide an example "external VG tool package". I did this a long time with callgrind, and it was working quite well (with the exception of biarch). I can come up with "lackey" externally packaged. This should also give us a test whether it is really working. As recently noted on the list, we currently install an invalid valgrind.pc file (with a nonsense @VG_PLATFORM@ string) :-( A drawback is that experimental tools sometimes need additions in the interface to VG core - but such a change needs agreement with core developers, and after doing the change, the external tool simply needs an SVN version as dependency. We could even integrate additions to the tool interface in 3.2.x to help external, experimental tools. Josef |