From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 053E97E7B for ; Tue, 21 Oct 2014 15:42:03 +0200 (CEST) Received: from [2001:470:8:a08:a03f:1c79:d585:4dec] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XgZpB-0006hr-HG; Tue, 21 Oct 2014 09:50:11 -0400 Date: Tue, 21 Oct 2014 09:50:08 -0400 From: Neil Horman To: Marc Sune Message-ID: <20141021135008.GD12795@hmsreliant.think-freely.org> References: <544617E0.80502@bisdn.de> <39275062.2hPoVIfNVy@xps13> <54462403.3060107@bisdn.de> <3074245.k7N1CrtUjD@xps13> <5446299A.5060400@bisdn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5446299A.5060400@bisdn.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] development/integration branch? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:42:03 -0000 On Tue, Oct 21, 2014 at 11:38:34AM +0200, Marc Sune wrote: > Thomas, > > On 21/10/14 11:28, Thomas Monjalon wrote: > >2014-10-21 11:14, Marc Sune: > >>On 21/10/14 10:46, Thomas Monjalon wrote: > >>>My balance is different because I have a simpler solution for Marc's problem: > >>> git fetch && git merge $(git tag | grep -v -- -rc | tail -n1) > >>We all know we _can_ do this. But is it really necessary? We should be > >>all as lazy as possible and make it easy for users IMHO. `git pull` is > >>easier :) > >Yes and lazy users download tarballs. > > At least for me, I stopped downloading DPDK tarballs after the third time I > had to upgrade the release. > >>I don't see any drawback of using a development branch, except if you > >>consider the extra push to master per release a drawback. > >No I don't care to push one more thing. > >But I care about the message brought by such change. It would mean that > >we can break the development branch and that most of developers don't test > >it nor base their patches on the latest commit. It's all about simple rules > >and messages. > > I understand your concern but, isn't peer reviewing meant to prevent this? > > >>Also think about new users downloading the repo for the first time. They > >>are forced to do this right now if they want to checkout the latest stable. > >New users will get the latest release and expect to see current work in > >progress right after cloning the git tree (in master branch). > >It's also more common to see work in progress in default branch in cgit. > I know, but I also know other projects do the way I proposed with success. > In any case it was just a suggestion to try to improve things. > > marc > Ideally, I think the best solution (and I've proposed this on the list several times), is to create a release branch when you begin tagging -rc branches, and use that branch for stabilization/testing prior to a release. Only fixes are allowed in such a branch, and can be merged with master post release-tagging. That would allow master to continue patch integration undeterred. Alternatively, doing like Linus does is also a fine idea, announce a merge window during which features are integrated, and after which new features are disallowed during the pre-release stabilization period. Doing so however requires a high degree of commitment to not make exceptions. If that is a concern, then a release branch is the safer approach, as it separates fixes from other patches. Neil