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
22.214.171.124 (US West)
126.96.36.199 (US East)
188.8.131.52 (Hong Kong)
Meeting ID: 344 730 807
Join by Skype for Business
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.
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!
It looks like when I originally set up appveyor for yt a few years ago I
did it incorrectly under my own github account instead of under the
There are instructions for how to sign up for an organization account on
Someone (not me, I'm not sure which e-mail to use) will need to follow
those instructions to set up a yt-project account on appveyor using an
e-mail address controlled by the project or a project maintainer. Once that
is set up you'll be able to update the webhook on the yt-project org to
point at the new test setup on the yt-project appveyor account.
Sorry for setting this up in a bad way and sorry for any confusion this has
caused, I honestly didn't realize until now that this was an issue.
This might be a real hot take, but I'd like to propose getting rid of the
install script. Below are a few reasons I think this is a good idea:
- yt can be reliably installed straight from pip or conda. Even installing
from source can be done reliably with "pip install -e ." assuming you have
pip. This has all been true for quite some time.
- The install script needs to be maintained. It's currently 718 lines long,
still has options for installing mercurial, rockstar, etc.
I will happily back down if anyone feels particularly attached to it, but I
think the combination of the above two points makes it more trouble than
I wrote up a reasonably short YTEP about why and how we could use the
traitlets library in some particular places in yt:
I look forward to comments and discussion!
We'll have a yt team meeting this Thursday 9/12 at 3pm BST (10am EDT). I'll
post a link to the hangout on slack when it begins. The steering committee
members will be there, but all are welcome to participate.