Each time we have a Pull Request (and everything which goes into master has to go through PRs) we should only give the final "Okay merge-able" if the commit messages are all okay.
I think such policies are best enforced by machines.
We could add a service somewhere on a server, which would listen to the GitHub webhook API and execute some validation script (there are enough out there, e.g. validate-commit-msg or fit-commit).
Could be done similar to https://github.com/Bernardstanislas/eslint-bot does stuff, but it would be cool if we really enforce this (instead of just comment-spamming).
I.e. we enforce currently that the Appveyor and Travis hooks run through before a Pull Request is allowed to be merged (thanks to GitHubs protected branches.
So we could use the Github Status API
Currently the layout is:
[NETWORK] allow only remote clients
This is a longer description why we no longer allow local clients.
which collapses to
[NETWORK] allow only remote clients in the history.
In respect to #37 we should maybe add info about the severity/type of that change (e.g. "fix" "refactor", ..) so we can generate the next version based on the commit messages.
Each time we have a Pull Request (and everything which goes into master has to go through PRs) we should only give the final "Okay merge-able" if the commit messages are all okay.
I think such policies are best enforced by machines.
We could add a service somewhere on a server, which would listen to the GitHub webhook API and execute some validation script (there are enough out there, e.g. validate-commit-msg or fit-commit). Could be done similar to https://github.com/Bernardstanislas/eslint-bot does stuff, but it would be cool if we really enforce this (instead of just comment-spamming). I.e. we enforce currently that the Appveyor and Travis hooks run through before a Pull Request is allowed to be merged (thanks to GitHubs protected branches. So we could use the Github Status API
Currently the layout is:
which collapses to
[NETWORK] allow only remote clients
in the history.In respect to #37 we should maybe add info about the severity/type of that change (e.g. "fix" "refactor", ..) so we can generate the next version based on the commit messages.