Andy>1). The test cases may succeed locally but
Andy
> may be failedAndy
> in CI for some reasons
Peter> This is not a problem
I would disagree. A patch might easily make the database incompatible with clients like JDBC.
Do current PostgreSQL tests catch that?
I don't think so.
However, that can be configured in PR CI.
Peter>You can do this now by sticking in your own travis or appveyor files and
Peter>pushing to your own github account. I do this from time to time
Do you expect that everybody reinvents the wheel?
---
I've recently come across
https://gitgitgadget.github.io/It is a tool that converts GitHub PRs into mailing list messages (and back).
What it does it enables contributors to send patches to the mailing list by creating PRs.
Of course, it does not replace the mailing list, however, it cross-posts comments (e.g. it posts email responses as GitHub comments).
It could significantly help contributors in the following ways:
1) One can create PR without really sending a patch (e.g. to estimate the number of broken tests)
2) It would be much easier to test patches since the number of CI checks can easily exceed the number of tests in make check-*.
It would help reviewers as well:
1) GitHub shows colored diffs which help to understand the patch
2) There's a "suggest change" feature which helps for cases like "fixing typos".
3) PR shows if the patch applies at all, and it shows which tests fail
4) It opens a way to trigger extra checks. For example, PR CI could trigger tests for **clients** like Java, C#, Ruby, etc, etc
WDYT on configuring gitgitgadget (or something like that) for PostgreSQL?