From dev-return-23652-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Oct 31 15:28:09 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 26700D3B6 for ; Wed, 31 Oct 2012 15:28:09 +0000 (UTC) Received: (qmail 69178 invoked by uid 500); 31 Oct 2012 15:28:08 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 68989 invoked by uid 500); 31 Oct 2012 15:28:07 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 68962 invoked by uid 99); 31 Oct 2012 15:28:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Oct 2012 15:28:07 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Oct 2012 15:27:59 +0000 Received: from rose.coup (unknown [178.19.216.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id E69FA14621 for ; Wed, 31 Oct 2012 16:21:41 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Subject: Re: branching in couchdb From: Jan Lehnardt In-Reply-To: Date: Wed, 31 Oct 2012 16:27:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <87B791B0-2812-41FB-A91B-E005EB785D9B@apache.org> References: <7D76050A-3095-46A3-81EA-2DB30E78E263@apache.org> To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1498) X-Virus-Checked: Checked by ClamAV on apache.org On Oct 31, 2012, at 16:23 , Paul Davis = wrote: > On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski = 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. >>=20 >> Adam >=20 > 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 --=20 >=20 >>=20 >> On Oct 31, 2012, at 10:40 AM, Jan Lehnardt wrote: >>=20 >>>=20 >>> On Oct 31, 2012, at 13:21 , Robert Newson = wrote: >>>=20 >>>> For my part, I was pretty content with the scheme we agreed to in = Dublin >>>> (-). >>>>=20 >>>> I would like to discuss the old branches that don't follow any = scheme at >>>> all, is it time we deleted those? >>>>=20 >>>> 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. >>>=20 >>> That sounds sane to me. >>>=20 >>> It seems to me the the enhanced branching model tries to do two = things: >>>=20 >>> 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.) >>>=20 >>> Please correct me if I am missing something. >>>=20 >>> 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 =93develop=94 branches. >>>=20 >>> 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. >>>=20 >>>=20 >>> 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=92t mind changing our branches to >>> jiranumber-feature-name-of-the-feature >>>=20 >>> E.g. 431-feature-cors, or 1500-bugfix-ibrowse-inbox-overflow >>>=20 >>> * * * >>>=20 >>>=20 >>> If nobody objects*, I'd sum this up two action items: >>>=20 >>> 1. update our wiki to name branches jiranumber-feature-name >>> instead of just jiranumber-name. (Jan) >>>=20 >>> 2. observe our branch/merge procedure closely to see whether >>> we should have a dedicated =93develop=94-branch. If we do, >>> switch to that model. (All) >>>=20 >>> Cheers >>> Jan >>> -- >>> * as per ASF Lazy Consensus. = (http://www.apache.org/foundation/glossary.html#LazyConsensus) >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> On 31 October 2012 09:16, Dave Cottlehuber = wrote: >>>>=20 >>>>> On 31 October 2012 09:07, Benoit Chesneau = wrote: >>>>>> Hello guys, >>>>>>=20 >>>>>> II would like to discuss a little about our branch naming. Today = we have >>>>>> conflicting docs somehow: >>>>>>=20 >>>>>> - >>>>> = http://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization >>>>>>=20 >>>>>> - http://wiki.apache.org/couchdb/ContributorWorkflow >>>>>>=20 >>>>>> and one another I don't find on the wiki now (without my = bookmarks) >>>>>>=20 >>>>>>=20 >>>>>> Maybe we can make a one page describing the branching workflow = and such ? >>>>>>=20 >>>>>> Also my understanding now is that branch should be named by >>>>>> _ >>>>>>=20 >>>>>> which sound good. >>>>>>=20 >>>>>> 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 : >>>>>>=20 >>>>>>=20 >>>>> = http://nxvl.blogspot.fr/2012/07/a-continous-delivery-git-branching-model.h= tml >>>>>>=20 >>>>>> and it could help for continuous integration when we will have = it. >>>>>>=20 >>>>>> In short : >>>>>>=20 >>>>>> - 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. >>>>>>=20 >>>>>> - a `fix/_` for changes fixing a bug >>>>>> - a `feature/_` for new features >>>>>> - usual X.X.x branch for releases (those we could name them = /release/X.X. >>>>>>=20 >>>>>> Thoughts? >>>>>>=20 >>>>>> - beno=EEt >>>>>=20 >>>>> +1 >>>>>=20 >>>>>=20 >>>>> = http://4.bp.blogspot.com/-t4yLz-et74A/UBIES98QPmI/AAAAAAAADGY/S5lwne9xpcM/= s1600/releaseFlow.png >>>>>=20 >>>>> seems very similar to the OTP approach as well. >>>>>=20 >>>>> Just tell me what I need to do :-) >>>>>=20 >>>>> A+D >>>>>=20 >>>=20 >>=20