From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10446 invoked by alias); 21 Jul 2016 12:52:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 10433 invoked by uid 89); 21 Jul 2016 12:52:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=holiday, policy, hear X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 21 Jul 2016 12:52:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 736A7116A2D; Thu, 21 Jul 2016 08:52:35 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id riiNExFN6Yu3; Thu, 21 Jul 2016 08:52:35 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 443D0116A29; Thu, 21 Jul 2016 08:52:35 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id BC490428D5; Thu, 21 Jul 2016 05:52:33 -0700 (PDT) Date: Thu, 21 Jul 2016 12:52:00 -0000 From: Joel Brobecker To: Yao Qi Cc: "gdb-patches@sourceware.org" Subject: Re: RFC: gdb-7.12 timeframe? Message-ID: <20160721125233.GA4846@adacore.com> References: <20160720172417.GA3601@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-07/txt/msg00250.txt.bz2 > > What I would like to propose is we try to create the branch soon. > > This means we make a call for blocking issues before the branch > > is created, and create the branch, say, one week from now. > > Issue a first pre-release then. > > We need collect issues first, and decide whether one week is enough to > stabilize the master and create branch then. I didn't follow the > regression tests in buildbot, but I'll take a look. Thanks for taking a look at the buildbot results. Regarding stabilization, there are two approaches. We can stabilize master to the point of near-release-readiness, which means we start holding patches that may be unsafe (a little bit like GCC does). Or we branch, and then decide which fixes we want for the branch. I was proposing the latter, which is a little more work for the branch, but allows development to continue on master. However, I am happy with either approach. We've used the former in the past, but given that we're entering the summer holiday period, it might take a while before we hear from some of us about issues that, under the stabilize-before-branch policy, we might want to fix before we branch. -- Joel