Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 86169 invoked from network); 1 Jun 2009 19:26:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Jun 2009 19:26:46 -0000 Received: (qmail 34056 invoked by uid 500); 1 Jun 2009 19:26:57 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 33990 invoked by uid 500); 1 Jun 2009 19:26:57 -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 33980 invoked by uid 99); 1 Jun 2009 19:26:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Jun 2009 19:26:57 +0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.68.5.9] (HELO relay00.pair.com) (209.68.5.9) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 01 Jun 2009 19:26:47 +0000 Received: (qmail 1536 invoked from network); 1 Jun 2009 19:26:25 -0000 Received: from 75.143.234.216 (HELO ?192.168.1.104?) (75.143.234.216) by relay00.pair.com with SMTP; 1 Jun 2009 19:26:25 -0000 X-pair-Authenticated: 75.143.234.216 Message-Id: From: Damien Katz To: dev@couchdb.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: changing branch commit merge block procedure Date: Mon, 1 Jun 2009 15:26:24 -0400 References: X-Mailer: Apple Mail (2.935.3) X-Virus-Checked: Checked by ClamAV on apache.org On Jun 1, 2009, at 3:00 PM, Chris Anderson wrote: > Devs, > > We've talked some about discontinuing use of svn's merge/block > procedure for maintaining old release branches, in favor just asking > committers to remember to put applicable patches into the 0.9.x > branch. My experience is that by default, patches shouldn't be included in branches. The point of branches is to provide a an increasingly stable code base, so that users of the branch can get updates and upgrade with little fear the update will introduce a change in behavior or regression into their production systems. Therefore, only patches that fix serious bugs (data loss, hangs) or regressions (features that worked in previous versions no longer work) should be considered for merging. Any patch that is merged back should be justifiable as to why it's important enough to risk destabilizing the branch. I think idea that we need to track all the patches going into trunk and the branches, because we might forget an important patch. Yes, we might forget an important patch, but then we can simply apply to the next release of the branch if its that important. Rather than track all the patches for all branches, we should rely on the community to tells us what's an important patch and what is not. -Damien > > > There is discussion to be had about what patches are applicable to > point release branches. > > Perspectives? > > Chris > > -- > Chris Anderson > http://jchrisa.net > http://couch.io