BTW, thanks for taking care of everything while I was gone/sick. Maybe we can get together once more sometime soon
Yeah, I get
<* and *>, too, I think; those seem pretty simple. But the type signature (<$) :: a -> f b -> f a isn't obvious to me, and from what you've said here and elsewhere I think I'm missing an intuition about the relationship between Appicative and Functors. I'll go back and spend an hour on it and I'm sure it will all come clear.
No problem. Yeah, we should definitely get together soon, assuming I don't have measles. :-/ (I'm hoping this is just an alergic reaction to the MMR vaccination I had last Friday. Someone at work apparently came in with measles.)
Ah ha! The
b type in the above is completely unused! (I just had to think for a moment about what fmap . const does.)
You should, I think. The US CDC page is currently recommending that any adult born after 1957 who hasn't already had all three diseases get vaccinated. I don't know if it's because the shots we all (should have) had as children are losing effectiveness for some reason, or if there's a pool of non-immunized people out there.
I'm sure that god-damned Jenny McCarthy hasn't been helping the situation at all.
Oh, very cool. I will have a look at that at some point, but I can't really do anything code-related until the pain subsides. (Right now I feel as if someone's pounded a large nail into my head.) Maybe you can co-ordinate with @E14n_twitter (I've confirmed in person that the's real Edward) to get more pages brought over and some CSS etc. done. He's got a branch with some work on this done already. And you guys have the password for the Netlify account, though it should just start working when the DNS is changed. Same for
lists.tlug.jp for the scraped copy of the current lists site. I didn't do any other subdomains; @ragga things we should just drop them and I agree. Everything should be pretty fully documented but ask here if you have questions.
Edward is on here using his twitter account, @E14n_twitter . That's why I mentioned it's ben verified by me, since you have no evidence otherwise that it's actually the same person @emiddleton that is a member of https://github.com/tlug.
At a quick glance, all looks good except the archive user/pw images which don't load on new.tlug.jp. Was that intentional?
In any case, lists.tlug.jp is now pointed at Jims server and looks to be working fine, which is kinda the most important as it's the portal for the mailing list.
Going forward, I think the main pages on both tlug.jp and lists.tlug.jp will have to be checked for consistency anyway.
Does netlify need to be changed to point to the new release branch each time?
We do not change the branch name holding the release; that would be as silly as changing the main branch name from
master every time we did a commit. Perhaps it's not clear, but the release branch is an entirely different set of files from the source branch. It's basically a commit of everything under the _site directory and nothing else.
Have you read through the docs on this?
Ah. BTW, I think you already know this, but I do strongly suggest rebase and fast-forward over actual merge commits. Anyway, the docs are all there, and hopefully do a better and more detailed job of describing the release process that I could by typing here. But if you have questions, I'll try to answer them. I would start by setting up a release branch for your dev branch and serving that from your personal netlify account, so you can have some confidence you understand what's going on. (@E14n_twitter may also be able to help; I think he's done this.)
Right now my branch is rebased on to master with everyone's latest stuff an no merge commits. If there's one command I can type right now, I'll do it. (./Test --prod-release ??) If it's more involved than that, I can look at it a little later. Really busy with work at the moment.
I don't know the exact git terminology, but you could set the github master branch to point to the same commit as dev/sjn/mediawiki-parser head and all would be good
No need for any additional merging/rebasing/etc.
Generally I do a quick read-through of all the commits I'm about to put on master before I do it, just to make sure they make sense, squash the "make mistake - do something else -fix previous mistake" commits, make sure the commits have explanations useful to others, and the like.