[Paraview-developers] On user submodule status

[Utkarsh Ayachit]

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
>