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 [1] 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.
>
> [1] 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/
>>

Reply via email to