Since it should not affect the behaviour of checkouts, I propose to start fixing documentation errors/omissions directly in master.
However I think we need to decide ASAP on the commit strategy. On 10 October 2016 at 16:29, sebb <seb...@gmail.com> wrote: > I've just noticed STATUS  which says that changes to master need > two +1s from Pony Mail committers. > > Is that still the case? > Do we want that still to apply? > > If so, I think there should be a trunk branch that is CTR, and a > release branch that is RTC along the lines of the STATUS file. > > However, I think the trunk (working) branch should be master, and > release branches should be called something else. > > Having 'master' as a release branch does not play well with the Git defaults. > Git seems to work best if 'master' is the trunk. > It should be easy to push to trunk (or provide pull requests for it). > Updating a release branch should require additional actions. > >  https://github.com/sebbASF/incubator-ponymail/blob/master/STATUS > > On 10 October 2016 at 12:33, Francesco Chicchiriccò <ilgro...@apache.org> > wrote: >> 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 <seb...@gmail.com> 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/ >>