Document periodic maintenance tasks (Stack snapshot update, cache clear, problem-specifications version check)

[petertseng]

In #435 we update to lts-7.9.

Is there a rule for how often we want to do this? For example, lts-7.15 is out now.

Or is it just "we update whenever someone feels like it"?

Let's see when a few versions were released since 7.9:

• 2016-11-14
• 2016-11-22
• 2016-11-28
• 2016-12-04
• 2016-12-12
• 2016-12-18
• 2017-01-08

Okay, so that means (normally) weekly. I don't think we particularly want to update every week. So, do we want to adopt some sort of thing like "let's update every month", or do we want it to be looser, like "we'll update if something is broken, otherwise we won't"?

[rbasso]

Any snapshot update generates additional downloads and compilation to the users, so I always avoided updating too frequently.

• Minor number updates usually require small downloads and some additional compilation, but they are generally safe. I guess they are supposed to only add new packages and make non-breaking updates to the existing packages (changes to the patch number).

• Major number updates require a lot of downloads and compilation, in some cases forcing download of a new GCC. Most of the time they reduce the number of available package.

I believe we can periodically update minor numbers, to allow more packages and also receive some non-breaking updates, but the major number bumps should be decided in a by-case basis.

We may also need to clear and rebuild the Travis-CI cache from time to time because of the updates, to check that everything builds from nothing - as expected - and to reduce the cache size, that keeps increasing as we build multiple snapshots. Usually I only do that when we change .travis.yml.

[petertseng]

I believe we can periodically update minor numbers, to allow more packages and also receive some non-breaking updates, but the major number bumps should be decided in a by-case basis.

Makes sense. How often do you think minor updates should be done? A month? Two months? Longer? Is there even a need for a set schedule?

We may also need to clear and rebuild the Travis-CI cache from time to time because of the updates, to check that everything builds from nothing - as expected - and to reduce the cache size, that keeps increasing as we build multiple snapshots.

Hmm... seems like it would be good to have these maintenance tasks written down somewhere so that we can be reminded of them (and/or any future maintainers)

[rbasso]

Is there even a need for a set schedule?

For minor updates, anytime someone feels it is too old seems good enough IMHO.This way is is up the one opening the PR if it is a week or a few months. :)

Hmm... seems like it would be good to have these maintenance tasks written down somewhere so that we can be reminded of them (and/or any future maintainers)

If the cache gets too big, it will probably timeout when updating or downloading it, so rebuild times will get bigger. We'll probably notice that, so I'm not too worried about it for now.

That said, I may be useful for new maintainers as you pointed out.

[petertseng]

depending on what model we decide for #416, keeping up to date with x-common may also be a task to be documented. I would document that, but since it's non-Haskell code I didn't want to inflict my code upon others. Anyway, I just run the script when I feel like it, no particular set schedule, just when I feel like things may be getting out of date

[petertseng]

to reduce the cache size,

let's see. Current cache size, 2202.35MB, I do not know when it was last cleared.

[petertseng]

After rebuild, which was triggered by me https://travis-ci.org/exercism/haskell/builds/357633588, cache size 921.02MB

[petertseng]

issue title: rename x-common to problem-specifications

[petertseng]

So basically this is about documentation that is useful for maintainers.

Consider also talking about the merging strategy, which, in brief, is:

• If the PR contains only one change and therefore is suitable to become one commit:
  • Slight preference for Squash and Merge. Create a Merge Commit is acceptable only if the PR was submitted as one commit.
  • Only if Squash and Merge is going to be used, Update from Master is acceptable. (Since Update from Master causes the "submitted as one commit" to be false, this should follow logically from the above)
• If the PR contains multiple changes and therefore must remain as separate commits:
  • Only Create a Merge Commit makes sense. Squash and Merge loses individual commits. Rebase and Merge makes the link to the PR only available when viewing the individual commits via web, which is too inconvenient.
  • Update from Master is unusable in this situation. Ask the submitter to rebase on master, or possibly do it yourself if the submitter left the "Allow edits from maintainers" box checked.