search

exercism / haskell

Exercism exercises in Haskell.
https://exercism.org/tracks/haskell
MIT License
494 stars 192 forks source link

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

Open petertseng opened 7 years ago

petertseng commented 7 years ago

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:

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 commented 7 years ago

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

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

to reduce the cache size,

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

petertseng commented 6 years ago

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

petertseng commented 5 years ago

issue title: rename x-common to problem-specifications

petertseng commented 5 years ago

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

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