README check: we can probably safely ignore deprecated exercises

[petertseng]

It would probably be fine if we modify https://github.com/exercism/haskell/blob/master/bin/ensure-readmes-are-updated.sh to ignore deprecated exercises.

It'll be a little unfortunate since it might mean we need to use jq or a similar tool to figure out whether the exercise is deprecated. But it's probably worth it since we will periodically do whole-track activities such as updating the Stack resolver.

Note that configlet generate will (if I'm not mistaken; I've never used it) still generate for the entire track, including deprecated exercises, so anyone who runs it will still get updates for them. If we want to change that, might want to talk to the configlet folks about that.

[sshine]

Does it happen often that READMEs for deprecated exercises get updated? I don't mind that we maintain deprecated exercises as long as it primarily means they are affected by batch jobs. This means that anyone can hypothetically put them in action again, or at least run them locally from git.

Today was the first time I used configlet, so I really don't know. But it sounds like making it compatible with config.json's deprecated flags could be preferrable to all tracks. Still, one of the two failing README's fixed in #778 (pythagorean-triplet) wasn't deprecated, so I don't know if it's worth the effort.

[sshine]

Why is gigasecond deprecated on the Haskell track?

It has been since #280 (2016-11-03) and that the reason is given in #192 (comment by rbasso).

Having performed this discovery, I think gigasecond qualifies as an exercise that might come back if someone really wants to, and so keeping it updated seems like a nice idea if it doesn't cost much.

[petertseng]

Does it happen often that READMEs for deprecated exercises get updated?

It's hard to quantify it, but unless it's deprecated across all of exercism, it's probably no more or less likely than any other exercise.

As you've discovered, there's a exercism-global deprecation (which, ultimately, is no more than an advisory), and track-level deprecations.

I don't mind that we maintain deprecated exercises as long as it primarily means they are affected by batch jobs. This means that anyone can hypothetically put them in action again, or at least run them locally from git.

That is true. For README updates, that's usually not so bad, since the content update is easy to automate. The act of documenting the related PRs from problem-specifications admittedly does need a little work, but it is not so bad, I hope.

Test updates usually require enough human intervention that I decided I didn't want to bother though, so all the deprecated exercises have not had test updates since they got deprecated, and I exclude them all from the output of https://github.com/petertseng/exercism-problem-specifications/blob/up-to-date/up-to-date/up-to-date.rb#L21 and/or https://github.com/petertseng/exercism-problem-specifications/blob/up-to-date/up-to-date/hs.rb .

I think gigasecond qualifies as an exercise that might come back if someone really wants to

That is true. No complaints from me about performing maintenance on any deprecated exercise, really.

[sshine]

Should this issue be closed, then?