[Paraview-developers] On user submodule status

[Biddiscombe, John A.]

I've recently added parallel support to my meshless (mostly SPH) tools and it has been fairly stable for some time. I have a number of users who would like to use it, but are not keen on building everything themselves (- even though for us, building paraview seems straightforward, apparently there are people out there who have trouble).

[mini rant: not part of the main point of this email :: I have been greatly disappointed with what happened to the point sprite plugin, and the H5Part reader plugin which were made part of paraview. In the process, tweaked by others, partially broken and then simply abandoned by me as I don't have time fight with getting stuff committed any more and I maintain my own versions of code and local users get my fixes (and yes, I admit that is is my own fault, but I'm still disappointed). Even all the work I did on upgrading HDF5 was ignored by kitware and instead of using the svn branch from the hdfgroup was hacked up and all branch/merge information lost for me, thus losing the fixes we needed for nice external hdf5 build break. Recently I tried pushing a few branches to stage, but the system requires so much work to get something accepted that I have again given up as it's easier to just tar up our local paraview with all the changes and give it to users. I must admit that I'm very sad these days that I can't just fix bugs in paraview any more like I used to].

I'd like to remove the two aforementioned plugins (principally h5part) from paraview and put them back into my meshless plugin, but contribute the whole new plugin back and maintain ownership of it. I have added a MIP renderer for particles, am in the process of fixing a number of issues with the point sprite renderer and as well as the parallel resampling tools have some other bits and pieces. The new splotch renderer is currently in its own plugin, but I am considering adding that also to the meshless one for simplicity (not sure though as it is self contained so really belongs on its own). The main point being that I'd like to be able to get stuff into releases without having to go through all the web based tools etc - for example - in order to get an "OpenID" I had to give my cellphone number and until recently I didn't use a cellphone so was excluded and I'm not happy about putting it into some google web thingy either).

Anyway, there was some talk years ago that when git support was added, we would be able to contribute a plugin, keep it in our own repository and have it referenced as a submodule in the paraview plugins tree. My idea would be that each time a paraview version was released, I'd tag or branch the plugin with that release and paraview proper would pick up that version and users would get it as standard, but I'd still have freedom to develop it as I see fit.

What's the word on the street?

JB
Note that the meshless plugin now includes its own copy of zoltan from trilinos and is therefore quite messy, adding the splotch renderer would also require adding splotch main lib too. These are currently built as part of their own subdirectory structure and been extensively tested on win/linux/maxOSX. My hope is that if a user can't get a plugin working, they just switch it off, but those of us who need and want it can develop it. I don't want to see these mini-libs moved into Utilities, but if other modules required them, then it wouldn't be a big deal.


--
John Biddiscombe,                        email:biddisco @.at.@ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Trevano 131, 6900 Lugano, Switzerland   | Fax:  +41 (91) 610.82.82


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20120603/f3435e35/attachment.htm>