> 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 <seb...@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 <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