Hi all, tl;dr: I'd like to cut a yt 3.4 release next week and want to know if anyone has an issue with that. I was a bit optimistic about what would get done at SciPy and unfortunately we were not able to fix all the open issues for 3.4 that week. Since then I've been trying to get the remaining issues squared away so we can cut yt 3.4 ASAP. You can see the issues on the 3.4 milestone here: https://github.com/yt-project/yt/issues?q=is%3Aopen+is%3Aissue+milestone%3A3... Currently all of the open issues have open pull requests to address them except for #1268. The pull request for #941 has been open a long time and still needs some work, which I am planning to do this weekend or early next week. I expect the pull requests for the other issues to be merged within the next week. For #1268, I think I'd like to punt on it, since it requires specialized knowledge about the inline yt interface in Enzo and no one has stepped up to work on it. I don't think it makes sense to delay the release on getting that issue fixed. If all that happens, that will leave us with zero open issues against the 3.4 milestone sometime next week. There are a bunch of new features that haven't been in a stable release yet along with a number of big fixes that have come in since yt 3.3.5 and I think we owe it to our contributors to not delay the release any longer than we absolutely need to. I'd like to know if anyone has an issue with getting a 3.4 release out as soon as all of the issues currently marked for 3.4 are merged. I'll volunteer to be the release manager in case there are issues with our release process now that we're on github and will update our release documentation accordingly. If anyone would like to help out that would be very much appreciated, particularly with writing the release notes. That's about it, let me know what you think, Nathan
Hi Nathan, On Fri, Aug 4, 2017 at 3:05 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi all,
tl;dr: I'd like to cut a yt 3.4 release next week and want to know if anyone has an issue with that.
I was a bit optimistic about what would get done at SciPy and unfortunately we were not able to fix all the open issues for 3.4 that week. Since then I've been trying to get the remaining issues squared away so we can cut yt 3.4 ASAP. You can see the issues on the 3.4 milestone here:
https://github.com/yt-project/yt/issues?q=is%3Aopen+is%3Aissue+milestone%3A3...
Currently all of the open issues have open pull requests to address them except for #1268. The pull request for #941 has been open a long time and still needs some work, which I am planning to do this weekend or early next week. I expect the pull requests for the other issues to be merged within the next week.
I will leave another comment, but I am no longer convinced this will work for datasets that require >21 bits of precision in the morton index, and I'm not certain that we should use it as is. It might be possible to switch the morton indexing over to complex128 or to use a three-integer key.
For #1268, I think I'd like to punt on it, since it requires specialized knowledge about the inline yt interface in Enzo and no one has stepped up to work on it. I don't think it makes sense to delay the release on getting that issue fixed.
I'm probably the only one who could do this right now, and I am pretty sure I won't be able to address it in the next few days.
If all that happens, that will leave us with zero open issues against the 3.4 milestone sometime next week. There are a bunch of new features that haven't been in a stable release yet along with a number of big fixes that have come in since yt 3.3.5 and I think we owe it to our contributors to not delay the release any longer than we absolutely need to.
Agreed.
I'd like to know if anyone has an issue with getting a 3.4 release out as soon as all of the issues currently marked for 3.4 are merged.
I'll volunteer to be the release manager in case there are issues with our release process now that we're on github and will update our release documentation accordingly. If anyone would like to help out that would be very much appreciated, particularly with writing the release notes.
Thanks for volunteering, and I would be happy to help write the release notes.
That's about it, let me know what you think,
Nathan
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I am A-OK with this schedule, and super happy to have a 3.4 released soon. Thank you for all of your hard work on this, Nathan, particularly all of the bugfixes! Cameron On Fri, Aug 4, 2017 at 1:09 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
On Fri, Aug 4, 2017 at 3:05 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi all,
tl;dr: I'd like to cut a yt 3.4 release next week and want to know if anyone has an issue with that.
I was a bit optimistic about what would get done at SciPy and unfortunately we were not able to fix all the open issues for 3.4 that week. Since then I've been trying to get the remaining issues squared away so we can cut yt 3.4 ASAP. You can see the issues on the 3.4 milestone here:
https://github.com/yt-project/yt/issues?q=is%3Aopen+is% 3Aissue+milestone%3A3.4
Currently all of the open issues have open pull requests to address them except for #1268. The pull request for #941 has been open a long time and still needs some work, which I am planning to do this weekend or early next week. I expect the pull requests for the other issues to be merged within the next week.
I will leave another comment, but I am no longer convinced this will work for datasets that require >21 bits of precision in the morton index, and I'm not certain that we should use it as is. It might be possible to switch the morton indexing over to complex128 or to use a three-integer key.
For #1268, I think I'd like to punt on it, since it requires specialized knowledge about the inline yt interface in Enzo and no one has stepped
up to
work on it. I don't think it makes sense to delay the release on getting that issue fixed.
I'm probably the only one who could do this right now, and I am pretty sure I won't be able to address it in the next few days.
If all that happens, that will leave us with zero open issues against the 3.4 milestone sometime next week. There are a bunch of new features that haven't been in a stable release yet along with a number of big fixes
that
have come in since yt 3.3.5 and I think we owe it to our contributors to not delay the release any longer than we absolutely need to.
Agreed.
I'd like to know if anyone has an issue with getting a 3.4 release out as soon as all of the issues currently marked for 3.4 are merged.
I'll volunteer to be the release manager in case there are issues with
our
release process now that we're on github and will update our release documentation accordingly. If anyone would like to help out that would be very much appreciated, particularly with writing the release notes.
Thanks for volunteering, and I would be happy to help write the release notes.
That's about it, let me know what you think,
Nathan
_______________________________________________ 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 NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
Quick update: we are almost ready. The release e-mail is drafted and is available to view here: https://hackmd.io/EYMxGNgEwRgDgLQFYAsBDKCUAYDswE0QAmATgVLm3AFNcliYRgBmIA==?b... There are two pull requests that need review that I think should go in for 3.4. If I could get some more eyes on them that would be very much appreciated: Issue with symlog axes scales and tick marks: https://github.com/yt-project/yt/pull/1502 Support AMR data in the WarpX frontend: https://github.com/yt-project/yt/pull/1531 In addition #1530 will also likely go in. That one already has two approves but I need to deal with some test flakiness before I can merge it. On Fri, Aug 4, 2017 at 3:05 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi all,
tl;dr: I'd like to cut a yt 3.4 release next week and want to know if anyone has an issue with that.
I was a bit optimistic about what would get done at SciPy and unfortunately we were not able to fix all the open issues for 3.4 that week. Since then I've been trying to get the remaining issues squared away so we can cut yt 3.4 ASAP. You can see the issues on the 3.4 milestone here:
https://github.com/yt-project/yt/issues?q=is%3Aopen+is% 3Aissue+milestone%3A3.4
Currently all of the open issues have open pull requests to address them except for #1268. The pull request for #941 has been open a long time and still needs some work, which I am planning to do this weekend or early next week. I expect the pull requests for the other issues to be merged within the next week.
For #1268, I think I'd like to punt on it, since it requires specialized knowledge about the inline yt interface in Enzo and no one has stepped up to work on it. I don't think it makes sense to delay the release on getting that issue fixed.
If all that happens, that will leave us with zero open issues against the 3.4 milestone sometime next week. There are a bunch of new features that haven't been in a stable release yet along with a number of big fixes that have come in since yt 3.3.5 and I think we owe it to our contributors to not delay the release any longer than we absolutely need to.
I'd like to know if anyone has an issue with getting a 3.4 release out as soon as all of the issues currently marked for 3.4 are merged.
I'll volunteer to be the release manager in case there are issues with our release process now that we're on github and will update our release documentation accordingly. If anyone would like to help out that would be very much appreciated, particularly with writing the release notes.
That's about it, let me know what you think,
Nathan
participants (3)
-
Cameron Hummels -
Matthew Turk -
Nathan Goldbaum