[v2.x] backports for 2.6 release

[cben]

Draft for upcoming 2.6.0 release (#281).
To be followed by merging #287.

Work notes for future

https://github.com/abonas/kubeclient/issues?utf8=%E2%9C%93&q=label%3Av2.x%2Fyes
Sorting manually by merge date.
($ hub issue --include-pulls -s '' -l v2.x/yes using hub is also handy but doesn't show merge date.)
Cherry-picking merge commits with:

git cherry-pick --mainline=1 $(git log --pretty='%H' origin/master --grep='Merge pull request #223')

EDIT: in future consider cherry-pick -x to link to original commit (though for PR merges the PR link is good enough)

Backported (newest last order)

#215 Code style: add parentheses around methods for test file v2.x/yes
#223 bump rubocop, fix offenses, use 2-space indent v2.x/yes
# Conflicts:
# .rubocop.yml
# lib/kubeclient/version.rb
rubocop fails a lot from this point, due to new cops & defaults.

#221 Include request info in exceptions to make it easy to see what reques… v2.x/yes
#229 Clarifying docs around process_template v2.x/yes
#231 relax requirement on recursive-open-struct v2.x/yes
#225 Remove limited entity list from Readme v2.x/yes
#232 Fix Minitest deprecation v2.x/yes
#236 bump rubocop to enforce what our style dictates v2.x/yes
#243 adjust readme to rubocop v2.x/yes
#205 make test output more readable by adding color v2.x/yes

#195 move exception into Kubeclient namespace v2.x/yes
- Test FAIL! see fix below
#233 Introduce Kubeclient::ResourceNotFoundError v2.x/yes
- Test FAIL! see fix below
#247 Support ruby 2.4 v2.x/yes
After above 3 PRs it's possible to completely revert backport changes of #271 (now closer to original #262) => tests PASS.

#261 Fixes warnings in test output (and a potential bug) v2.x/yes
#267 cascade delete entities with a delete_option parameter. v2.x/yes
#279 Recurse over arrays for watch notices v2.x/yes
#280 Catch EBADF when watch_stream fails v2.x/yes
#286 allow running tests with ruby test_foo.rb test v2.x/yes
#285 implement as: :raw for watch v2.x/yes
- Test FAIL on Ruby 2.0 — this commit used 2.1+ syntax.
=> Made small change e9817fd to use 2.0 syntax.

#288 Fix README comment on Kubeclient::HttpError bug v2.x/yes
#295 Add ruby 2.5.0 to Travis test matrix v2.x/yes

- Rubocop still errors.  Remaining errors were fixed on master by #253 and #269 but not backporting those.
=> Disabled couple cops on v2.x.

rake test passed locally after each backport except 3 FAIL mentioned above.

[cben]

This is ready. Please review non-"Merge pull request #nnn" commits carefully!

Ended up disabling couple rubocops on v2.x.
An alternative could be backport only style changes from #253 (cben@536b281) + fix one place (cben@f5a05e5).
I feel weird about making extra style changes on release branch only to please rubocop.
(we did backport many style PRs but that was out of fear we'd otherwise get conflicts)

[moolitayer]

@cben please get more reviewers to review this. I'm on a course and flying next week so I have limited availability, regardless this is a large PR and should be reviewed by more then one person.

Why shouldn't we backport only minimal/needed changes and concentrate on releasing master?

[cben]

@grosser @jhernand @simon3z can you help reviewing?
Most are clean cherry picks, only the 223 one had conflicts.
There is one clean revert (see commit message).
And last two "[v2.x only]" extra commits by me need review.

EDIT: let me know if prefer smaller PRs and see a way to split this...

[cben]

Why shouldn't we backport only minimal/needed changes and concentrate on releasing master?

Who'd be the target audience for "minimial needed changes" release?
We have 21 PRs here that are not released yet, that we deemed backward-compatible. About half of these are style & tests, but still, a lot of user-visible improvements.

Every user could have different opinion what are "minimial needed" changes (as an example, I think ManageIQ only "needs" 2 fixes plus cares about ruby 2 more for ruby 2.4 and 2.5 test coverage).
And then if someone asks for more, and we end doing another release with out of order backports, those are painful and add up to more work and risk :-(

If we release "maximal possible changes" — all 21 PRs — in 2.6, we "catch up to the debt".
This brings v2.x textually pretty close to master (+82 -39 lines).
After that, we can mostly forget about v2.x branch (and if we ever need another 2.x release it's not scary).

[moolitayer]

Who'd be the target audience for "minimial needed changes" release?

Any stable product out there using kubeclient.

We have 21 PRs here that are not released yet, that we deemed backward-compatible. About half of these are style & tests, but still, a lot of user-visible improvements.

That's why we are releasing master which we are going to do regardless.

As we are going to handle kubeclient release I would want to create a commitment to release master often enough, but would not like to commit to cheery picking that much. In the words of someone wise:
#281 (comment)

I accept we already discussed this and time was invested so will not object any longer.

Next time I do want to concentrate on releases from master.

[moolitayer]

New commits e9817fd & d39a9c1 Look good, the revert 2381575 as well.

[simon3z]

I haven't reviewed in detail but we discussed few of these PRs in person and the backport policy we put in place is good. 👍

[cben]

shelving this. did a 3.0 and doing a small 2.5.2 (see #281 (comment)).

If anyone wants additional 2.x release, let us know what you need.