Proposed: release dates for 2.6, 2.6.x, and 3.0
Hi all,
I have issued a pull request which needs to be discussed; I'd rather
that be here as it's a more central location.
https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dat...
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
implemented.
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)
https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroify...
(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.
Hello Matt,
Just let me say that I am a huge fan of this plan. I think that it strikes
the right balance between moving forward and backwards compatibility.
Also, the last week in I spent in Madison really convinced me of the
practical need for YTEP-17. Please let me know if you need any more
help with this.
Be Well
Anthony
On Tue, Oct 1, 2013 at 1:50 PM, Matthew Turk
Hi all,
I have issued a pull request which needs to be discussed; I'd rather that be here as it's a more central location.
https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dat...
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 implemented.
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)
https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroify... (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.
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. <unbold> 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."
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Matt,
On Tue, Oct 1, 2013 at 12:50 PM, Matthew Turk
* 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.
How will this work inside the repo? Will be using branches and a single repository? Will we accept pull requests into the 2.X codebase or only accept PRs for 3.X and then backport as appropriate?
* 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 implemented.
I also think it's important to address these two issues: https://bitbucket.org/yt_analysis/yt/issue/552/cut_region-doesnt-work-in-30 https://bitbucket.org/yt_analysis/yt/issue/499/missing-hierarchy-functions
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."
Agreed! I'm excited for everything to move over the 3.0 - it will be a relief to make changes without having to worry about future merge conflicts.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, Oct 1, 2013 at 4:06 PM, Nathan Goldbaum
Matt,
On Tue, Oct 1, 2013 at 12:50 PM, Matthew Turk
wrote: * 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.
How will this work inside the repo? Will be using branches and a single repository? Will we accept pull requests into the 2.X codebase or only accept PRs for 3.X and then backport as appropriate?
We have a few options. My inclination is that we should not yet make the branch "yt" refer to the 3.0 codebase, simply because then people might "yt update" themselves into it. I am inclined to say we continue with yt-3.0 as a branch for development until we have ensured full coverage and a compatibility layer, which may not be until 3.1 or even later. This is somewhat similar to what Python did, and I want to ensure we retain a strong community foundation.
* 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 implemented.
I also think it's important to address these two issues:
https://bitbucket.org/yt_analysis/yt/issue/552/cut_region-doesnt-work-in-30 https://bitbucket.org/yt_analysis/yt/issue/499/missing-hierarchy-functions
Fair points. I've assigned both to me and made them blockers.
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."
Agreed! I'm excited for everything to move over the 3.0 - it will be a relief to make changes without having to worry about future merge conflicts.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
It was my understanding (but I have not tested this personally) that
several of the recipes in the cookbook could not yet be reproduced in 3.x.
Is this true? If so, is the idea for 2.6 to be the last major version of
2.x and then all development to be shifted to 3.0, and part of this early
3.0 development would be on making sure that all of the functionality from
2.x work in 3.x?
I very much understand your statement of being in a perpetual state of
never-yet-ready, but I think before we push more and more people to the 3.x
branch, we need to make sure all the major pieces of functionality (mostly
demonstrated through cookbook recipes) works in 3.x. This shiftover from
2.x to 3.x could, in fact, be the major facilitator of this, I just want to
confirm the status of things. If that's the case, then I'm in favor of
this.
Cameron
On Tue, Oct 1, 2013 at 1:06 PM, Nathan Goldbaum
Matt,
On Tue, Oct 1, 2013 at 12:50 PM, Matthew Turk
wrote: * 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.
How will this work inside the repo? Will be using branches and a single repository? Will we accept pull requests into the 2.X codebase or only accept PRs for 3.X and then backport as appropriate?
* 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 implemented.
I also think it's important to address these two issues:
https://bitbucket.org/yt_analysis/yt/issue/552/cut_region-doesnt-work-in-30 https://bitbucket.org/yt_analysis/yt/issue/499/missing-hierarchy-functions
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."
Agreed! I'm excited for everything to move over the 3.0 - it will be a relief to make changes without having to worry about future merge conflicts.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
On Tue, Oct 1, 2013 at 4:13 PM, Cameron Hummels
It was my understanding (but I have not tested this personally) that several of the recipes in the cookbook could not yet be reproduced in 3.x. Is this true?
There are two aspects to this. 1) The recipes will not work once the YTEPs have been merged. They will all need to be updated, since while I do intend to have a compatibility layer as a requirement for the merging of those two big things, the cookbook recipes will not be using the compatibility layer. 2) The cookbook recipes, other than the boolean and cut regions which I previously noted are not working, all work as of the PR I just issued. Additionally, I would classify updating the documentation and cookbooks as part of the "bolded for emphasis" comments in my previous email, where I took responsibility for updating the docs to 3.0.
If so, is the idea for 2.6 to be the last major version of 2.x and then all development to be shifted to 3.0, and part of this early 3.0
Yes.
development would be on making sure that all of the functionality from 2.x work in 3.x?
The major items not working are cut_regions, boolean regions, and clump finding. Anything else has either not been used and reported to be failing, or is working. The testing suite passes and in fact is more extensive than the 2.X testing suite.
I very much understand your statement of being in a perpetual state of never-yet-ready, but I think before we push more and more people to the 3.x branch, we need to make sure all the major pieces of functionality (mostly demonstrated through cookbook recipes) works in 3.x. This shiftover from 2.x to 3.x could, in fact, be the major facilitator of this, I just want to confirm the status of things. If that's the case, then I'm in favor of this.
I think my goals are number one, to get anyone on this mailing list who has not already tried to use 3.0 to try to use it, and number two, to then attempt to migrate the broader community -- which I hope will eventually bring with it a growth in the community. The infrastructure of 3.0 has been shaken out considerably. The corner cases, the unforeseen bugs, all of that are the things that need to be examined and worked with, and I can only identify so many possibilities. As I noted, there are extensive unit tests and answer tests, but this will not catch everything. Following that, making the backwards incompatible changes (noted above) will be possible, and then we can attempt to shift development. -Matt
Cameron
On Tue, Oct 1, 2013 at 1:06 PM, Nathan Goldbaum
wrote: Matt,
On Tue, Oct 1, 2013 at 12:50 PM, Matthew Turk
wrote: * 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.
How will this work inside the repo? Will be using branches and a single repository? Will we accept pull requests into the 2.X codebase or only accept PRs for 3.X and then backport as appropriate?
* 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 implemented.
I also think it's important to address these two issues:
https://bitbucket.org/yt_analysis/yt/issue/552/cut_region-doesnt-work-in-30 https://bitbucket.org/yt_analysis/yt/issue/499/missing-hierarchy-functions
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."
Agreed! I'm excited for everything to move over the 3.0 - it will be a relief to make changes without having to worry about future merge conflicts.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
A corrollary of this is: when should the yt-3.0 branch development be
moved primarily into the main yt_analysis/yt repository. This is not
the same as making it the main or stable line.
Upsides: easier to switch between mainline and 3.0, easier to do
releases, and easier for people out there to switch and to update.
Downsides: higher turnover in relatively large ways on our main
repository, although outside of the main branch, and there are a
number of extant forks of 3.0 already that would be orphaned.
I'm probably fine with this happening soon, I think. The YTEP
suggests a release date for 3.0a4 of October 15, but I'd be fine
pushing the yt-3.0 branch into yt_analysis/yt anytime. It's unlikely
that someone who doesn't want 3.0 would blindly update to 3.0 if "tip"
is in 3.0, so I don't think that's a huge concern.
-Matt
On Tue, Oct 1, 2013 at 3:50 PM, Matthew Turk
Hi all,
I have issued a pull request which needs to be discussed; I'd rather that be here as it's a more central location.
https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dat...
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 implemented.
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) https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroify... (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.
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. <unbold> 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."
-Matt
I was under the impression that yt-3.0 development was already being done
in the yt_analysis/yt repository. There is definitely a yt-3.0 branch in
there. Is it not being used? If not, I don't think a strong case can be
made for people trying it until then.
On the branch naming question, if we were to merge yt-3.0 development into
the yt branch, what would happen to the yt-3.0 branch? Since branches are
forever in hg, it will always be hanging around.
Finally, I've said this before to a few people and it's been touched on in
this thread, but I don't think the main hangup for a 3.0 release is the
code, but the documentation. Unless I am mistaken, there is effectively no
documentation of what has changed between 2.x and 3.0. This needs to be
near the top of the priority list for organizing for a release.
Britton
On Fri, Oct 4, 2013 at 6:19 PM, Matthew Turk
Hi all,
A corrollary of this is: when should the yt-3.0 branch development be moved primarily into the main yt_analysis/yt repository. This is not the same as making it the main or stable line.
Upsides: easier to switch between mainline and 3.0, easier to do releases, and easier for people out there to switch and to update. Downsides: higher turnover in relatively large ways on our main repository, although outside of the main branch, and there are a number of extant forks of 3.0 already that would be orphaned.
I'm probably fine with this happening soon, I think. The YTEP suggests a release date for 3.0a4 of October 15, but I'd be fine pushing the yt-3.0 branch into yt_analysis/yt anytime. It's unlikely that someone who doesn't want 3.0 would blindly update to 3.0 if "tip" is in 3.0, so I don't think that's a huge concern.
-Matt
On Tue, Oct 1, 2013 at 3:50 PM, Matthew Turk
wrote: Hi all,
I have issued a pull request which needs to be discussed; I'd rather that be here as it's a more central location.
https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dat...
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 implemented.
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)
https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroify...
(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.
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. <unbold> 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."
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Mon, Oct 7, 2013 at 6:01 AM, Britton Smith
I was under the impression that yt-3.0 development was already being done in the yt_analysis/yt repository. There is definitely a yt-3.0 branch in there. Is it not being used? If not, I don't think a strong case can be made for people trying it until then.
It is, but it's only updated when a new "release" happens -- so most high-cadence development happens in the other repo.
On the branch naming question, if we were to merge yt-3.0 development into the yt branch, what would happen to the yt-3.0 branch? Since branches are forever in hg, it will always be hanging around.
We'd "close" the branch, so it would exist but would not show up as an open branch anymore.
Finally, I've said this before to a few people and it's been touched on in this thread, but I don't think the main hangup for a 3.0 release is the code, but the documentation. Unless I am mistaken, there is effectively no documentation of what has changed between 2.x and 3.0. This needs to be near the top of the priority list for organizing for a release.
I agree with this. Fortunately, minus the things that are listed in the YTEPs that haven't been merged yet (i.e., "dataset" and unifying datasets and indices) most of the changes have been developer-facing rather than user-facing.
Britton
On Fri, Oct 4, 2013 at 6:19 PM, Matthew Turk
wrote: Hi all,
A corrollary of this is: when should the yt-3.0 branch development be moved primarily into the main yt_analysis/yt repository. This is not the same as making it the main or stable line.
Upsides: easier to switch between mainline and 3.0, easier to do releases, and easier for people out there to switch and to update. Downsides: higher turnover in relatively large ways on our main repository, although outside of the main branch, and there are a number of extant forks of 3.0 already that would be orphaned.
I'm probably fine with this happening soon, I think. The YTEP suggests a release date for 3.0a4 of October 15, but I'd be fine pushing the yt-3.0 branch into yt_analysis/yt anytime. It's unlikely that someone who doesn't want 3.0 would blindly update to 3.0 if "tip" is in 3.0, so I don't think that's a huge concern.
-Matt
On Tue, Oct 1, 2013 at 3:50 PM, Matthew Turk
wrote: Hi all,
I have issued a pull request which needs to be discussed; I'd rather that be here as it's a more central location.
https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dat...
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 implemented.
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)
https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroify... (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.
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. <unbold> 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."
-Matt
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (5)
-
Anthony Scopatz
-
Britton Smith
-
Cameron Hummels
-
Matthew Turk
-
Nathan Goldbaum