[Paraview-developers] On user submodule status

Tue Jun 12 07:21:57 EDT 2012

Utkarsh

Option 1: I have no real knowledge of superbuild, but if all you need is a git tag/branch/sha of the most recent release and a URL/repo to get it from that seems fine.

Option 2: Build binaries separately. Seems like adding work unnecessarily.

Option 3: I had imagined that I have a public git repo, kitware clones it locally in the 'User contributed plugins' section of your git space. Inside the paraview Tree, the git clone is a submodule much like Xdmf or IceT, and When a new version is available, I go through the process of submitting a patch to paraview with the correct submodule sha. This gets included in the next version.

?

JB

-----Original Message-----
From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] 
Sent: 05 June 2012 04:41
To: Biddiscombe, John A.
Cc: paraview-developers at paraview.org
Subject: Re: [Paraview-developers] On user submodule status

John,

There are a couple of possibilities for contributing external plugins that are managed externally, but none of them include bringing the plugin in as a submodule. Since without Kitware having write access to the plugin, we cannot ensure that the plugin keeps on building/working as changes keep on happening to the git-master version.

The options are as follows:
* We could including the submodule in the ParaView-Superbuild. That way it gets built and packaged when ParaView binaries are built using the superbuild scripts. However to ensure that the official ParaView binaries include the plugin, you'll have to ensure that plugin works with the release candidate in time for the official release, or the plugin will be skipped.
* You manage the plugin entirely separately, however, we can still build official binary compatible  versions for the plugin and upload it to the paraview download site. This way you can update the plugin at your own pace without being tightly tied with the ParaView release cycle.
* You can suggest another low-maintenance option.

Utkarsh

On Sun, Jun 3, 2012 at 2:30 PM, Biddiscombe, John A. <biddisco at cscs.ch> wrote:
> 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
>
>
>
>
>
>
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>