If we decided to go with CTR (which I have no issues with), we should make it explicit so that if anybody decided to auto-deploy master, it'd be clear that master might not always be stable (in the sense of having had Rs on a C).
Other than that, everything you suggest is more than sensible IMO. On Mon, 10 Oct 2016 at 12:03 sebb <[email protected]> wrote: > Does the project operate on RTC (Review Then Commit) or CTR for committers? > > Or does it depend on the nature of the change? > > I am used to making simple fixes such as typos and documentation with > just the commit message for documentation. > > For bugs, I would expect to see an issue raised, and any fixes linked to > that. > > For enhancements, often a dev discussion is needed before an > enhancment issue is raised and fixed. > > Given that changes can always be reverted, and AFAIK changes are not > automatically deployed, it seems to me that CTR should be sufficient > for all updates to the code base (with the obvious exception of > security fixes) >
