@jbrockmendel This needs a rebase it seems. I've become gunshy since the last time :P

Was the rebase successful?

Seems like it, though I have a mild preference for actually using git rebase over git merge. There are positives and negatives of both approaches. With git merge, when you have to actually resolve something in the merge commit, I think it can cause problems with backports and cherry-picks. Also, even if you're not resolving anything, I don't know if the state of "when master was merged back into this PR" needs to be preserved in the history.

With rebase, the problem is that you're actually re-writing history, which means you may lose what the original implementation was, you have to do force pushes, and the actual commits change (meaning that if you've signed your commits you have to re-sign them.

Not sure why I'm going on about this so much, it's a toss-up so do whatever you prefer :P

Hm, not sure why this is failing on Windows after I rebased against the latest master. Seems like some issue with freezegun. That could be either a freezegun problem or a dateutil problem in this particular branch that's being manifested through freezegun (since freezegun depends on dateutil).

That said, it's failing because it's failing to import syslog. It may be that Appveyor deployed Python without syslog for some reason.

I think this is an appveyor problem. I just restarted a random build and it broke.

Yah the rebase vs merge conversation seems to be happening a lot these days. I'm still getting up the learning curve with rebase.

Is the appveyor thing something I can be useful with, or just moral support?

@jbrockmendel See spulec/freezegun#214 and pytest-dev/py#169 . This is a problem somewhere upstream. If it's not fixed relatively quickly, we can add an explicit dependency on py and pin it to the last known working version on Appveyor.