On Mon, May 2, 2016 at 7:18 PM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
On 05/02/2016 06:26 PM, Nathan Goldbaum wrote:
Hi all,

I'm moving some discussion from the comments in issue #1212 over to the
mailing list:

https://bitbucket.org/yt_analysis/yt/issues/1212

I wanted to check with the list since Cameron objected a bit in the issue
discussion.

The issue Cameron identifies is pretty serious, but fully fixing it will
require pretty substantial work - adding support for octree data to the
AMRKDTree.

I've gone ahead and marked it for version 3.4 - i.e. that it shouldn't be a
blocker for the 3.3 release. I've also created issue 1215:

https://bitbucket.org/yt_analysis/yt/issues/1215

which will be fixed when yt produces a useful error message rather than seg
faulting when trying to construct an AMRKDTree for unsupported data.

I think that requiring someone to add support for octree data to the
AMRKDTree before we release 3.3 is effectively delaying the 3.3 release
arbitrarily far into the future, since no one is currently willing to work
on that project. That would be unfortunate, because there's lots of cool
stuff people have worked on that deserves a stable release.

-Nathan

Hi,
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.

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?

I think it's been an issue since we began to support octree data in yt 3.0.
 

Cheers,
Kacper
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org