There is a very similar discussion ongoing on the groovy incubation mailing 
list.

The rub is that for commits to be accepted into geode, they have to be pushed 
to the apache git repo. This removes the option of using github pull requests 
as a way of following through the whole code acceptance flow.

It does though mean that you can create forks of the github mirror, open a PR 
and then locally merge that onto the apache git as another git remote alongside 
github. 

I would suggest having most work in the github world, and a published method 
for new contributors to do a normal github fork and pull approach. Contributors 
can then use a process to migrate that to apache git once it is approved for 
merge. That allows use of the github infra for review and a public face where, 
at the moment, people would expect it to be.

This is something of a seperate thing from the branching‎ model, sorry for 
hijacking the thread.

David.

--
David Dawson
CEO 

Simplicity Itself Ltd
Tel +7866011256
Skype davidadawson
[email protected]

http://www.simplicityitself.com
  Original Message  
From: Pid
Sent: Wednesday, 6 May 2015 09:59
To: [email protected]
Reply To: [email protected]
Subject: Re: Branching model

On 01/05/2015 17:50, Dan Smith wrote:
> On Fri, May 1, 2015 at 7:07 AM, jan i <[email protected]> wrote:
> 
>> Public feature branches should only be used, when multiple people work on a
>> feature. A feature branch is started after the intention is made clear on
>> dev@

Pushing a feature branch could be a simple way to offer it for review.

I understand that Geode will be RTC (Review-Then-Commit), so we should
discuss how the review process will work in combination with git-flow.


> One thing we've done within our organization is make a distinction between
> public feature branches - which are longer lived with multiple committers,
> and "work in progress" branches for individual changes which are generally
> owned by a single committer and are very short lived.
> 
> Would it make sense for committers to create work in progress branches on
> the apache github, or should these be maintained outside apache
> infastructure?

As above, I think the mechanism by which proposed changes are to be
reviewed has some bearing here.


IMHO it doesn't make sense to maintain branches elsewhere, unless they
are solely in your local copy of the git repository and there's some
other mechanism for reviewing them before they are merged into the
develop branch on the origin repo.


Thoughts?


p



> -Dan
> 


-- 

[key:62590808]

Reply via email to