On 10/10/2016 13:24, Ulises wrote:
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).
As one of the people currently running in production a bare checkout
from master, I am quite sensible to this argument, but find anyway the
proposal below to look good.
Other than that, everything you suggest is more than sensible IMO.
+1
Regards.
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)
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
