<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The downside of dropping the wikis is that they hold a lot of information that probably would not be found in code. For instance, the Sandia tutorials are
found there, along with the SC Tutorials. We also have locations for the configuration files, and my release testing.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> David E DeMarle [mailto:dave.demarle@kitware.com]
<br>
<b>Sent:</b> Monday, January 26, 2015 8:34 AM<br>
<b>To:</b> Utkarsh Ayachit<br>
<b>Cc:</b> Scott, W Alan; paraview-developers@paraview.org<br>
<b>Subject:</b> [EXTERNAL] Re: [Paraview-developers] CMake Version<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">Sounds like a good idea to me, AS LONG AS the mechanics of finding and changing said information is easy to find and described well.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">David E DeMarle<br>
Kitware, Inc.<br>
R&D Engineer<br>
21 Corporate Drive<br>
Clifton Park, NY 12065-8662<br>
Phone: 518-881-4909<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Mon, Jan 26, 2015 at 10:30 AM, Utkarsh Ayachit <<a href="mailto:utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@kitware.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">I do see a bigger issue that Alan raises, which is a fair one. Wikis<br>
have too much stale text! I keep wondering if we should drop the Wikis<br>
entirely and go to documenting in code so it's easier to maintain. We<br>
already have started documenting things like API changes, etc in the<br>
Doxygen pages[1]. Maybe we should migrate everything there.<br>
<br>
The one reason for Wikis is that its easier for external folks to<br>
change. But if we move to github/gitlab workflow soon, people will be<br>
able to edit files and create merge requests on the Web directly as<br>
well. Hence those who are actually keep on editing the documentation<br>
will indeed be able to.<br>
<br>
What do folks think?<br>
<br>
Utkarsh<br>
<br>
<br>
[1] <a href="http://www.paraview.org/ParaView3/Doc/Nightly/www/cxx-doc/index.html" target="_blank">
http://www.paraview.org/ParaView3/Doc/Nightly/www/cxx-doc/index.html</a><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><br>
On Mon, Jan 26, 2015 at 10:22 AM, David E DeMarle<br>
<<a href="mailto:dave.demarle@kitware.com">dave.demarle@kitware.com</a>> wrote:<br>
> We want to document two things.<br>
><br>
> 1) What version ranges the ParaView source code is compatible with.<br>
> 2) What specific versions were the Kitware binaries built so that people can<br>
> build and distribute plugins that work with them.<br>
><br>
><br>
> On Friday, January 23, 2015, Scott, W Alan <<a href="mailto:wascott@sandia.gov">wascott@sandia.gov</a>> wrote:<br>
>><br>
>> Dan,<br>
>><br>
>> OK, now we are saying that we have two locations that we document what<br>
>> versions of packages we use. There are actually three, if you include<br>
>> inside the superbuild itself. I strongly feel that there should be one<br>
>> location that everyone can go to when they want to know what version of<br>
>> packages are to be used. Currently, these two locations are:<br>
>><br>
>><br>
>><br>
>> <a href="http://www.paraview.org/Wiki/ParaView:Build_And_Install#Prerequisites" target="_blank">
http://www.paraview.org/Wiki/ParaView:Build_And_Install#Prerequisites</a><br>
>><br>
>> and<br>
>><br>
>> <a href="http://www.paraview.org/Wiki/ParaView_Binaries" target="_blank">http://www.paraview.org/Wiki/ParaView_Binaries</a><br>
>><br>
>><br>
>><br>
>> Alan<br>
>><br>
>> p.s. – not trying to shoot the messenger here – thanks for the reply. My<br>
>> point is just that we should document the version of what builds with<br>
>> ParaView one place, having gone through weeks of hell building cgns.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> From: Dan Lipsa [mailto:<a href="mailto:dan.lipsa@kitware.com">dan.lipsa@kitware.com</a>]<br>
>> Sent: Monday, January 12, 2015 8:57 PM<br>
>> To: Scott, W Alan<br>
>> Cc: David E DeMarle; Marcus D. Hanwell; <a href="mailto:paraview-developers@paraview.org">
paraview-developers@paraview.org</a><br>
>> Subject: Re: [Paraview-developers] [EXTERNAL] Re: CMake Version<br>
>><br>
>><br>
>><br>
>> <a href="http://www.paraview.org/Wiki/ParaView:Build_And_Install#Prerequisites" target="_blank">
http://www.paraview.org/Wiki/ParaView:Build_And_Install#Prerequisites</a><br>
>><br>
>><br>
>><br>
>> has the correct minimum version required for cmake 2.8.8.<br>
>><br>
>><br>
>><br>
>> Dan<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Jan 9, 2015 at 12:10 PM, Scott, W Alan <<a href="mailto:wascott@sandia.gov">wascott@sandia.gov</a>> wrote:<br>
>><br>
>> I am hearing that it makes sense to leave current minimum cmake version<br>
>> for VTK. That is OK with me. It is also always good to know that you can<br>
>> always use latest/ greatest Cmake. But, that isn’t true for all packages<br>
>> (and I believe latest Cmake has been incompatible in the past). Let’s<br>
>> update the ParaView wiki to show what Cmake version is used for the builds?<br>
>> Surprisingly, upgrading Cmake versions isn’t trivial for some of us that<br>
>> build somewhere around a dozen platforms, and I don’t like having to guess<br>
>> what version to use...<br>
>><br>
>><br>
>><br>
>> Thanks all!<br>
>><br>
>><br>
>><br>
>> Alan<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> From: Paraview-developers<br>
>> [mailto:<a href="mailto:paraview-developers-bounces@paraview.org">paraview-developers-bounces@paraview.org</a>] On Behalf Of David E<br>
>> DeMarle<br>
>> Sent: Friday, January 09, 2015 8:53 AM<br>
>> To: Marcus D. Hanwell<br>
>> Cc: <a href="mailto:paraview-developers@paraview.org">paraview-developers@paraview.org</a><br>
>> Subject: [EXTERNAL] Re: [Paraview-developers] CMake Version<br>
>><br>
>><br>
>><br>
>> If there isn't a compelling reason I think we should remain<br>
>> conservative, and it sounds like there is not in this case (especially<br>
>> for a dependency that is pretty optional for many of our users).<br>
>><br>
>><br>
>><br>
>> Agreed. One factor in the minimum required decision is what the popular<br>
>> Linux distros have readily on hand.<br>
>><br>
>><br>
>><br>
>> You<br>
>> can generally always use the latest CMake if you choose, but making<br>
>> that the minimum makes it harder for others to compile and use our<br>
>> code (often using the packaged CMake).<br>
>><br>
>><br>
>><br>
>> Agreed again. The "faraway" submission in the dependencies track of the<br>
>> vtk dashboard exists to verity that CMake master works for VTK.<br>
>> Unfortunately it didn't submit today so someone needs to shove it.<br>
>><br>
>><br>
>><br>
>> Marcus<br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Paraview-developers mailing list<br>
>> <a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
>> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">
http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
>><br>
>><br>
><br>
><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in">> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at:<br>
> <a href="http://markmail.org/search/?q=Paraview-developers" target="_blank">http://markmail.org/search/?q=Paraview-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">
http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
</body>
</html>