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 14:40:03 GMT

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