I've been working on a PR (https://github.com/yt-project/yt/pull/2286) that converts yt's testing framework from nose to pytest. I believe that it's mostly ready to go, so I was writing to see what everyone's thoughts on this change are, if there is any feedback on my implementation, and if anyone would be willing to help review it, since there are quite a few changes. Thanks, and have a good weekend!
What: yt user/developer workshop
Where: Edinburgh, UK
When: June 29 to July 3, 2020
I'm very pleased to announce that there will be a yt user/developer
workshop at the Higgs Centre for Theoretical Physics at University of
Edinburgh from June 29 to July 3, 2020. The workshop will begin with a
couple days of tutorials for new users and then transition into development
activities. This will be a good opportunity to meet and join the yt
community. More information to follow, but mark your calendars and diaries
now. I hope to see you next summer!
We used to have a weekly PR triage meeting, but then, we stopped
having one! I have re-created one, set up for 9:30AM Central time on
Fridays for the next couple weeks. They worked really well while we
did them. I've also left it be a bit long so that if there's any
non-PR-triage work we can or should do, we can do that too.
I know this isn't ideal for West Coast folks, but I'd be happy to set
up another one as well. Looking forward to seeing you! The
invitation is copied below, and there's a link to a URL that will add
it to your calendar. I'll try (but will likely forget) to send out
Matthew Turk is inviting you to a scheduled Zoom meeting.
Topic: yt PR triage and co-working
Time: Sep 20, 2019 09:30 AM Central Time (US and Canada)
Every week on Fri, until Nov 1, 2019, 7 occurrence(s)
Sep 20, 2019 09:30 AM
Sep 27, 2019 09:30 AM
Oct 4, 2019 09:30 AM
Oct 11, 2019 09:30 AM
Oct 18, 2019 09:30 AM
Oct 25, 2019 09:30 AM
Nov 1, 2019 09:30 AM
Please download and import the following iCalendar (.ics) files to
your calendar system.
Join Zoom Meeting
One tap mobile
+19292056099,,344730807# US (New York)
+16699006833,,344730807# US (San Jose)
Dial by your location
+1 929 205 6099 US (New York)
+1 669 900 6833 US (San Jose)
+1 647 558 0588 Canada
+49 30 3080 6188 Germany
+49 30 5679 5800 Germany
+49 69 7104 9922 Germany
+82 2 6105 4111 South Korea
+82 2 6022 2322 South Korea
+44 203 051 2874 United Kingdom
+44 203 481 5237 United Kingdom
+44 203 966 3809 United Kingdom
+44 131 460 1196 United Kingdom
+81 524 564 439 Japan
+81 3 4578 1488 Japan
+61 8 7150 1149 Australia
+61 2 8015 6011 Australia
+52 554 161 4288 Mexico
+52 229 910 0061 Mexico
Meeting ID: 344 730 807
Find your local number: https://zoom.us/u/abzljuNmCN
Join by SIP
Join by H.323
220.127.116.11 (US West)
18.104.22.168 (US East)
22.214.171.124 (Hong Kong)
Meeting ID: 344 730 807
Join by Skype for Business
As many of you know, the yt-project has been growing and evolving over the
past several years (to new domains, to new datasets, to support new
packages, etc.). To accompany that growth, we'd like to take the
opportunity to update our governance structure. We've been working on
updating our governance model for the yt project and I've submitted two
companion PRs with drafts of this updated governance:
Our existing governance structure is located at
The first PR is to a new governance repository, where our governance
documentation will live separately from the YTEPs. This will allow us to
maintain and minorly update our governance without having to update YTEP.
The second PR is to the YTEP repository and generally outlines the core
values and ideas we want our governance structure to reflect. Hopefully all
of the things I've listed in the YTEP are reflected in the governance docs.
As members of the community, I'd like to solicit feedback from all of you
about these governance documents. Do these reflect our community values?
Should we add anything? Do you feel everything is clear? Is this too much
governance for our community right now? Is there something that's missing?
Feel free to reply here or comment on the pull requests! Our governance
will be better with your feedback.
PS - I tried to build in a mentorship structure into our maintainer
structure to help with onboarding new maintainers. I'd especially like to
know if you all think this would be valuable to you or if it is adding
unnecessary constraints to our community.
I posted this as a comment on #2172, but I wanted to note it here.
Right now the holdup for merging yt-4 into master is the answer
testing. We actually would not expect the answers to be the same
between the two (at the very least because the ordering of values will
be different) so we need to do some kind of manually inspection.
My plan for addressing answer testing differences, which I will start
by doing manually:
* All grid and octree data should have either the same, or
justifiably different answers. In my view, "justifiably different"
includes unit changes, and also includes changes as a result of
particles being selected on edges of grid boundaries. These will be
documented. (See #2195 )
* Results for all data selections in SPH and particle datasets should
be identical in count and values, although the order will likely be
different. To address this, we will have a "sorting order" field that
is the morton index of the particles, and the values will be sorted
and compared. This should help to identify situations where different
numbers of particles are being selected (typically they should not be,
except for situations related to smoothing length.)
* Manual inspection of visualizations that avoid meshing in 4.0 and
that utilize meshing in 3.x.
I believe this should cover most of the cases, and will take to the
next step of verification. To conduct these tests, I'm going to work
on a script that outputs the appropriate values into an HDF5 file, and
then compare the results for both. This will be somewhat distinct from
the answer testing and designed for ease of exploration.
Once I have a system prepared for this, I will post back here, and I
will likely put the results online to view.