Several open Greenkeeper-PRs

@keithamus , @meeber I was sleeping for a whole while in this project - sorry for that.

But I`ve awoken and found an awful lot of Greenkeeper-PRs having a failing build. I want to tackle those PRs now but I want to talk a strategy with you first.

First of all, there is a lot of updated dependencies which simply fly around build-tooling. We could ask ourselves if we really need those updates.

Then there is a bunch of outdated PRs of updated dependncies. For example ESLint has PRs for laround 6 different Versions. For those, I would just close the old-version-PRs and only leave the newest ones - if we already gonna put work into this, then let’s do it right.

That should already clear the field for a better overview. What do you think?

[keithamus]

Firstly

I was sleeping for a whole while in this project - sorry for that.

Please don’t ever feel guilty or apologetic for stepping back for a while. This is not your job, you should only do it when you feel happy to!

talk a strategy with you first

The PRs from greenkeeper are only meant to trigger for two reasons:

1. a project has updated to a version outside of your semantic range
2. a project has updated to a version within your semantic range, but has broken your build

1 is really useful, because if the tests are passing for that new version, we can merge right away and all is fine. If the tests fail then we can investigate what the problem is, and potentially just close it as its out of our semver range.

2 should be just as useful, because any failure we should investigate and hopefully fix. Sadly most of these - in our case - are saucelabs failures. For example if we have a look at #48 - we can see the build (https://travis-ci.org/chaijs/type-detect/jobs/144520639) failed because IE9 timed out. Sadly this becomes a false negative - we’re warned about a failure but really it’s just saucelabs “uptime” issues. I’ve actually spoken to saucelabs about this but haven’t heard much back.

The point of this explanation is to demonstrate an ideal strategy for these PRs. So my proposed strategy is thus:

• If a PR has ⚠️ in the subject, it’s a failing build in our semver range. Check Travis. If its a saucelab timeout, its safe to close. Examples: #41, #42, #45, #48, #54
• If a PR has a ⚠️ and Travis is failing for another reason. Then we should investigate further, perhaps set up a discussion inside of the PR. Examples: (well, none right now)
• If a PR has a 🚨 then its a failing build outside of our semver range. If it’s a devdep, we can probably just close it right away, unless you feel like you have time to look at fixing. If it’s a main dependency then we should look to see why it’s breaking and try to solve so we keep our deps up to date.
• If a PR has a 🚀 it’s outside of our semver range, and could either be passing or failing. Passing 🚀s can be merged right away. Failing ones should use the same strategy as 🚨s.

I’ll cc @meeber and @lucasfcosta to this so we can all discuss 😄

[keithamus]

a) a PR is opened by @keithamus or greenkeeper

I don’t have any special access to saucelabs within travis, nor does the greenkeeper account, so to speak. It has a lot more to do with your second point:

b) when a commit is made on this repo (either directly or through a merged PR).

^ This is how greenkeeper works. Any PR made from within this repo rather than a fork gets to use SauceLabs, because it is considered trusted code (as only a select few have access to write to this repo). Greenkeeper commits direct to this repo, therefore the tests are run on travis and given access to the saucelabs credentials.

So, @davelosert - as you have access to write to this repo, you are able to push to branches from within the repo, which will trigger a saucelabs test. If you want to play with the concurrency setting, feel free to do so in a branch from this repo (again, just to reiterate, not from your fork).