couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: branching in couchdb
Date Wed, 31 Oct 2012 15:27:36 GMT

On Oct 31, 2012, at 16:23 , Paul Davis <paul.joseph.davis@gmail.com> wrote:

> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <kocolosk@apache.org> wrote:
>> No objection from me, Jan.  I don't see the need for a dedicated "develop" branch
at the moment, but then I've not worked intensively on a project which had one.
>> 
>> Adam
> 
> I think the intention there is if you have a sufficiently large test
> suite that accurately represents reality. Thus when you're landing
> features in quick succession you have a place to test the combination
> before they "go live". I'm not sure we really have that (also
> considering that we run our test suite locally and don't rely on a
> central CI server).

Good summary!

I think we want to be working towards that, but yeah, we are not
really there yet, and we don't have many concurrent features and
fixes going on.

But again, I am happy to reconsider this, when we run into issues
with the current setup.

Cheers
Jan
-- 

> 
>> 
>> On Oct 31, 2012, at 10:40 AM, Jan Lehnardt <jan@apache.org> wrote:
>> 
>>> 
>>> On Oct 31, 2012, at 13:21 , Robert Newson <robert.newson@gmail.com> wrote:
>>> 
>>>> For my part, I was pretty content with the scheme we agreed to in Dublin
>>>> (<jira>-<shortdesc>).
>>>> 
>>>> I would like to discuss the old branches that don't follow any scheme at
>>>> all, is it time we deleted those?
>>>> 
>>>> For going forward, I think every jira-shortdesc branch lives forever. 'git
>>>> branch --no-merged master' will show all the branches we haven't merged in,
>>>> and I advocate that as our mechanism for figuring out which branches are
>>>> dead, rather than removing the sometimes-useful history of a ticket.
>>> 
>>> That sounds sane to me.
>>> 
>>> It seems to me the the enhanced branching model tries to do two things:
>>> 
>>> 1. Allow fast and lose merging of a bigger number of feature branches
>>>  to make fast deployment and CI easier and non-blocking.
>>> 2. Establish a naming convention for branches of different types
>>>  (hotfix, feature etc.)
>>> 
>>> Please correct me if I am missing something.
>>> 
>>> For the moment I don't see that we have too many concurrent feature
>>> branches in CouchDB. So for the time being, I think we are okay with
>>> treating the release branches as the “develop” branches.
>>> 
>>> I think it will become obvious when that is going to be no longer
>>> sufficient and I would totally support starting to use the develop-
>>> branch method as soon as we hit any issues with the currently
>>> described setup.
>>> 
>>> 
>>> As for 2. we tag our branch names with the JIRA number which gives
>>> us the branch-type as well. So technically the information is one
>>> lookup away, but I wouldn’t mind changing our branches to
>>> jiranumber-feature-name-of-the-feature
>>> 
>>> E.g. 431-feature-cors, or 1500-bugfix-ibrowse-inbox-overflow
>>> 
>>> * * *
>>> 
>>> 
>>> If nobody objects*, I'd sum this up two action items:
>>> 
>>> 1. update our wiki to name branches jiranumber-feature-name
>>>   instead of just jiranumber-name. (Jan)
>>> 
>>> 2. observe our branch/merge procedure closely to see whether
>>>   we should have a dedicated “develop”-branch. If we do,
>>>   switch to that model. (All)
>>> 
>>> Cheers
>>> Jan
>>> --
>>> * as per ASF Lazy Consensus. (http://www.apache.org/foundation/glossary.html#LazyConsensus)
>>> 
>>> 
>>>> 
>>>> 
>>>> On 31 October 2012 09:16, Dave Cottlehuber <dch@jsonified.com> wrote:
>>>> 
>>>>> On 31 October 2012 09:07, Benoit Chesneau <bchesneau@gmail.com>
wrote:
>>>>>> Hello guys,
>>>>>> 
>>>>>> II would like to discuss a little about our branch naming. Today
we have
>>>>>> conflicting docs somehow:
>>>>>> 
>>>>>> -
>>>>> http://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization
>>>>>> 
>>>>>> - http://wiki.apache.org/couchdb/ContributorWorkflow
>>>>>> 
>>>>>> and one another I don't find on the wiki now (without my bookmarks)
>>>>>> 
>>>>>> 
>>>>>> Maybe we can make a one page describing the branching workflow and
such ?
>>>>>> 
>>>>>> Also my understanding now is that branch should be named by
>>>>>> <TicketNumber>_<shortdescr>
>>>>>> 
>>>>>> which sound good.
>>>>>> 
>>>>>> I would like to introduce another level to help us when we have to
look
>>>>> on
>>>>>> different branches. This is mainly based on that doc :
>>>>>> 
>>>>>> 
>>>>> http://nxvl.blogspot.fr/2012/07/a-continous-delivery-git-branching-model.html
>>>>>> 
>>>>>> and it could help for continuous integration when we will have it.
>>>>>> 
>>>>>> In short :
>>>>>> 
>>>>>> - a develop branch where all patches should land before to go in
master.
>>>>>> This branch can be used for final review and make sure it doesn't
break
>>>>>> anything else.
>>>>>> 
>>>>>> - a `fix/<TicketNumber>_<shortdescr>`  for changes fixing
a bug
>>>>>> - a `feature/<TicketNumber>_<shortdescr>` for new features
>>>>>> - usual X.X.x branch for releases (those we could name them /release/X.X.
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>>> - benoît
>>>>> 
>>>>> +1
>>>>> 
>>>>> 
>>>>> http://4.bp.blogspot.com/-t4yLz-et74A/UBIES98QPmI/AAAAAAAADGY/S5lwne9xpcM/s1600/releaseFlow.png
>>>>> 
>>>>> seems very similar to the OTP approach as well.
>>>>> 
>>>>> Just tell me what I need to do :-)
>>>>> 
>>>>> A+D
>>>>> 
>>> 
>> 


Mime
View raw message