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>
>> 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
>>> that master might not always be stable (in the sense of having had Rs on a
>> 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.
>>> 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
>>>> 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
>>>> 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
>> Member at The Apache Software Foundation
>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail