<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 7:18 PM, Kacper Kowalik <span dir="ltr"><<a href="mailto:xarthisius.kk@gmail.com" target="_blank">xarthisius.kk@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 class="HOEnZb"><div class="h5">On 05/02/2016 06:26 PM, Nathan Goldbaum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I'm moving some discussion from the comments in issue #1212 over to the<br>
mailing list:<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt/issues/1212" rel="noreferrer" target="_blank">https://bitbucket.org/yt_analysis/yt/issues/1212</a><br>
<br>
I wanted to check with the list since Cameron objected a bit in the issue<br>
discussion.<br>
<br>
The issue Cameron identifies is pretty serious, but fully fixing it will<br>
require pretty substantial work - adding support for octree data to the<br>
AMRKDTree.<br>
<br>
I've gone ahead and marked it for version 3.4 - i.e. that it shouldn't be a<br>
blocker for the 3.3 release. I've also created issue 1215:<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt/issues/1215" rel="noreferrer" target="_blank">https://bitbucket.org/yt_analysis/yt/issues/1215</a><br>
<br>
which will be fixed when yt produces a useful error message rather than seg<br>
faulting when trying to construct an AMRKDTree for unsupported data.<br>
<br>
I think that requiring someone to add support for octree data to the<br>
AMRKDTree before we release 3.3 is effectively delaying the 3.3 release<br>
arbitrarily far into the future, since no one is currently willing to work<br>
on that project. That would be unfortunate, because there's lots of cool<br>
stuff people have worked on that deserves a stable release.<br>
<br>
-Nathan<br>
</blockquote>
<br></div></div>
Hi,<br>
the rule of thumb I've always used within other open source project is that bugs that are not regressions shouldn't block release/stabilization of new versions.<br>
<br>
If we adopted such a rule, it would be a matter of answering the question whether #1212 applies to 3.2 as well, or was it introduced in 3.3?<br></blockquote><div><br></div><div>I think it's been an issue since we began to support octree data in yt 3.0.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Kacper<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br></div></div>