<div dir="ltr">Thanks for the feedback Dave. I think that we would allow for more than os/compiler fixes if we will maintain VTK 6 for several years. We would allow for general bug fixes also. My hope would be that those in the community that need VTK 6 would help out significantly. It sounds like David is volunteering to help maintain such a version. I am sure that there would be others also. The main challenge I can think of is how we will keep track of what was merged into VTK 6. Maybe we need to ++ our processes to integrate the issue tracker more tightly, the way ParaView does. This would enable us to keep track of things better... I'd like to hear some feedback and suggestions on this.<div><br></div><div>-berk</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 10:57 AM, David E DeMarle <span dir="ltr"><<a href="mailto:dave.demarle@kitware.com" target="_blank">dave.demarle@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">5.10 was the first time we attempted any kind of long term support (<a href="http://public.kitware.com/pipermail/vtk-developers/2013-October/029905.html" target="_blank">http://public.kitware.com/pipermail/vtk-developers/2013-October/029905.html</a>) eh? Curiously, we just turned off the 5.10 branch dashboard testers last week. We did so to streamline the dashboard presentation and to repurpose the underused hardware cycles for buildbot tests.<div><div><br></div><div>My thoughts on that first attempt:</div><div>1) Despite annoying people who wanted bug fixes and improvements merged, I personally agreed with the rule of only allowing os/compiler update fixes.<br></div><div><br></div><div>2) It was wasteful to dedicate machines to testing (poorly since there were few of them) the branch nightly</div><div><div>- Buildbot and CDash updates should improve testing (2) this time around.</div></div><div><br></div><div>3) I did not like how opaque the contributions process for new patches was.</div><div><div>4) I did not like the one person bottleneck to getting contributions merged (the lumbering troll guarding the branch)</div></div><div>5) I did not like manually keeping track of topics to merge and ensuring that were clean</div><div>- gitlab should should help with improving the contribution process (3,4,5).<br></div><div><br></div><div>In summary, once we set up buildbot, cdash and gitlab to allow it, I think we'll be much more successful this time around.</div><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div>David E DeMarle<br>Kitware, Inc.<br>R&D Engineer<br>21 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: <a href="tel:518-881-4909" value="+15188814909" target="_blank">518-881-4909</a></div></div>
<br><div class="gmail_quote"><div><div class="h5">On Wed, Jun 10, 2015 at 8:16 PM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi David,<div><br></div><div>Sounds good. We had a discussion about testing at Kitware. With the new infrastructure we have in place, we won't need nightly testing. We can just test when changes are made to master. CDash now supports showing latest dashboard results every day, no matter how long ago they were run. This will allow us to throw as many dashboard systems as we use on the latest version to older versions, since changes will happen rarely...</div><div><br></div><div>We need to figure out the details of how we will do this. It is likely VTK 8 and 9 will come fairly quickly after 7 and they are very likely to bring fairly big changes both in terms of API as well as supported compilers. So my current thinking is to have VTK 6 live for several years (3-5?) while 7, 8 and 9 would come and go fairly quickly. So anyone who doesn't want to ride this new wave of changes could stick to 6 but those that jump on 7 or later will have to be willing to move forward... Does this make sense? Alternative suggestions are welcome. With the caveat that maintaining multiple versions of several years would be challenging for the community.</div><div><br></div><div>Best,</div><div>-berk</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 12:14 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Berk,<div><br></div><div>I'd love to see long-term support for older versions of VTK.  It could be done without placing any burden on anyone but the people who need it, if a couple simple rules are followed:</div><div><br></div><div>1) When we move to VTK 7, an LTS branch should be created for VTK 6, and this branch should remain open for X years.  Merge requests etc. for this branch should be handled exactly as for the master branch.  We could have a list of developers willing to review patches for this branch on the wiki (I'd certainly be willing to do so).</div><div><br></div><div>2) There should be no expectation of binary releases from an LTS branch, that would just create extra work for Kitware and would probably end up slowing down the whole process.</div><div><br></div><div>3) There would have to be a section of the dashboard available for each LTS branch for nightly testing at least.  Merges into the LTS branch should be rare enough that @home testing would be unnecessary.  I realize that this might entail some gitlab customization.</div><div><br></div><div>I was not happy with how fast VTK 5 was dropped.  If there had been some way that I could have helped to support it, then I would have.</div><div><br></div><div>Here in academia, it's very common for projects to be put on hold for two or three years due to temporary lack of funding, or because a lab goes for a couple years without a grad student who has the necessary expertise.  So if a grad student gets stuck with a project that requires a version of VTK that won't work on a modern system, it becomes very difficult to even get started.</div><div><br></div><div> - David</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 9:31 AM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Maybe one way of addressing this issue would be to keep two versions maintained for a longer period? For example, we could commit to maintaining (minor bug fixes and limited testing only) VTK 6 for 3 years after we release VTK 7... That way customer that are stuck on old compiler can benefit from bug fixes and testing longer. If they want newer features, they would have to update. Given that we are likely to move to VTK 7 and then 8 pretty quickly, even longer than 3 years may be warranted.<div><br></div><div>I would argue for aiming for (mostly) C++ 11 by VTK 8, probably around late 2016.</div><span><font color="#888888"><div><br></div><div>-berk</div></font></span></div></blockquote></div></div></div></div>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtkusers" target="_blank">http://markmail.org/search/?q=vtkusers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtkusers" target="_blank">http://public.kitware.com/mailman/listinfo/vtkusers</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>