couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: branching in couchdb
Date Wed, 31 Oct 2012 15:18:20 GMT
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

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