I have issued a pull request which needs to be discussed; I'd rather
that be here as it's a more central location.
I would like to propose:
* 2.6 be released on November 1, 2013, which gives several days after
the "doc sprint." I will be working on docs leading up to the doc
sprint. The code is in a good state at this point and we can release
it at any time, but the documentation is the primary blocker for 2.6.
* I have added three maintenance releases, every three months, for
2.6.1, 2.6.2, 2.6.3 and 2.6.4. This is because will *not* be
deprecating the 2.x series.
* 3.0 has been added with a tentative release on January 1, 2014. I
have assessed the reliability of the code, and it seems to me that
*even as it is*, it is considerably better than the 2.x line of
development. The remaining struggles are all in documentation. A
handful of operations are still outstanding -- clump finding and
boolean objects most notably -- but the vast, vast majority are
I have one other reason I want to push for a release: I would like to
diverge the two lines of development in some substantial ways, and I
do not think we can do that until we have a clear end-game. These
ways are all enumerated in these two YTEPs:
https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html (by Casey)
(by me, not yet accepted)
Both of these actually have commits outstanding, but which we have
been reluctant to merge into mainline 3.0 because they will make
future merging *into* 3.0 quite difficult. They also both break
backwards compat, and before we get *any* more uptake of 3.0 than we
already have, I'd like to merge them in.
<bold for emphasis!>
An unavoidable requirement for these two YTEPs to be merged in is that
a 3.0 documentation build must exist and must be up to date. This is
*my* responsibility, and I have begun to undertake it.
I'd like to resolve this by proposing we wind down development on 2.X
as best we can, and instead attempt to focus resources on 3.0. Until
we do that, the biggest fish of the refactor/redesign simply can't
land, which means we're in a self-perpetuating cycle of never getting
to the point of being "ready."
New issue 671: ARTIO root cell count does not match up
The number of root cells selected is not correct when we run through `.mask` as opposed to through `.select`. I believe this is likely my fault somewhere in computing the SFC start, etc, and the selection of cells. I am assigning this bug to myself.
This script demonstrates the problem on the sample data:
This came up while adding a variation of these calculations to the test suite.
For the record, here is what it outputs on my machine:
2073808 2085480 1.00562829346
76347 76347 1.0
122941 122941 1.0
98129 98129 1.0
46316 46316 1.0
148136 148136 1.0
37511 37511 1.0
78035 78035 1.0
82925 82925 1.0
7640 7640 1.0
These should all be the same:
2771788 2783460.0 2783460
These should be the same:
Note that I manually overrode the `list_sfc_ranges` to cover the full domain for the purposes of this test.
The docs page for adding a new frontend has some odd syntax that I - and
Sphinx, apparently - don't know how to parse that references a
[[CodeSupportLevels|table]]. Anyone know where this table exists, or what
it should be changed to?