|
From: Bryan M. <om...@br...> - 2005-11-05 21:03:40
|
On Saturday 05 Nov 2005 20:12, Josef Weidendorfer wrote: > On Saturday 05 November 2005 09:53, Oswald Buddenhagen wrote: > > On Sat, Nov 05, 2005 at 01:03:33AM +0100, Josef Weidendorfer wrote: > > > Why don't you make a separately distributed, external VG tool out of > > > it? > > > > > because being integrated gives you more visibility, relieves you from > > release management, more or less assures continuous code review from > > people who ought to know what they are talking about and finally the > > user has less effort to obtain + install it. > > That is all good and fine, but VGs history tells me: there was not one > tool being accepted to be included into VG unless the author was one > of the VG core authors itself. And there is a reason: if the author > disappears, all the maintenance falls back to the core developers. > And at such a point, it is better to drop it again. This even happened > to one tool from a core developer: helgrind. And that was even "only" > because of changed funtionality of VG core. > > > on the downside, you're bound to the core project's release schedule ... > > No. Unfortunately that is the case even with external tools: As the tool > API's major number changes with every major VG release, I am "forced" to > come up with a release of my external tool ASAP. There were 6 bug reports > for debian because Callgrind did not catch up in time with VG 3 :-( > > > > It is a lot easier to be not the only one checking that a VG > > > installation provides enough for such external tools. > > > > > ... and if the project is supposed to have library character, it gets > > less testing in this area. > > > > really, it's all the same as with kde. ;) > > VG has a small active developer community, you can not compare it to KDE > (and even KDE has unmaintained code in its core distribution!). > In the KDE case, a big plus to be in a core package is to get i18n. > This is not a problem with VG. > > So perhaps an idea for VG >= 3.2: Make a VG core distribution with pure > library character, without any tool at all, and provide all tools externally. > > Visibility is done via valgrinds web site, listing all tools available. > I am quite sure that Fedora/SuSE/Debian etc. would provide packages > for all such tools. And by calling the package e.g. "valgrind-omega" > it probably will be installed by users interested in valgrind. > > Josef > I appreciate the comments - thanks. The main thing for me is to get it working to such an extent that it is usefull to people. Whilst there is a lot that I can do on my own, there is a lot more that can be done either directly or with the help and guidance of others. If the guys don't want it in, that's fine but omega has to be in a visible enough place so that people know that it is available and that they are welcome to hack on it. There are many ways of achieving that but my preference is for it to be in with the core toolset. If it looks like that wont happen, I will work out the best way forwards from that point. This tool wont be going away - I have written it to use at work whilst we transition some code so I will be supporting it at least for internal use for quite some time to come. It just strikes me that sharing it out is the right thing to do. Bryan "Brain Murders" Meredith |