[yt-dev] Should support for octree data in the AMRKDTree be a blocker for 3.3?

[Kacper Kowalik]

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?

Cheers,
Kacper