You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ponymail.apache.org by sebb <se...@gmail.com> on 2016/10/10 11:03:07 UTC
RTC or CTR or a mixture?
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)
Re: RTC or CTR or a mixture?
Posted by Ulises <ul...@gmail.com>.
> Since it should not affect the behaviour of checkouts, I propose to start
fixing documentation errors/omissions directly in master.
+1
On Wed, 12 Oct 2016 at 10:28 sebb <se...@gmail.com> wrote:
> 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 <se...@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ò <il...@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 <se...@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/
> >>
>
Re: RTC or CTR or a mixture?
Posted by sebb <se...@gmail.com>.
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 <se...@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ò <il...@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 <se...@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/
>>
Re: RTC or CTR or a mixture?
Posted by sebb <se...@gmail.com>.
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ò <il...@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 <se...@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/
>
Re: RTC or CTR or a mixture?
Posted by Francesco Chicchiriccò <il...@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 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 <se...@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/
Re: RTC or CTR or a mixture?
Posted by Ulises <ul...@gmail.com>.
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 <se...@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)
>