From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117300 invoked by alias); 15 Oct 2019 15:53:45 -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 117292 invoked by uid 89); 15 Oct 2019 15:53:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=establishing, backported, Thinking, Delay 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 ESMTP; Tue, 15 Oct 2019 15:53:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D266A5608F; Tue, 15 Oct 2019 11:53:42 -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 m1RTuA5uWM6F; Tue, 15 Oct 2019 11:53:42 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 95A0B5608C; Tue, 15 Oct 2019 11:53:42 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id D41E1838B5; Tue, 15 Oct 2019 08:53:40 -0700 (PDT) Date: Tue, 15 Oct 2019 15:53:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: GDB 9.1 release: Start of stabilization period ? Message-ID: <20191015155340.GE13252@adacore.com> References: <20191012191938.GA2675@adacore.com> <87k197te6i.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k197te6i.fsf@tromey.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2019-10/txt/msg00427.txt.bz2 > Another question I have is whether we want to try to finish the "move > gdbserver" project. The first step (moving gnulib) is in, but recall > that this broke in-tree builds -- which would be the major reason to > wait for this. A couple subsequent steps (moving readline and moving > gdbsupport) have been submitted, but the final step has not. In my opinion, this is the type of change that would benefit from being done early in the development cycle compared to just before branching. But, if there is an imperative reason why this should be part of the next release cycle, then we can decide that we want to wait for it first. > Based on the other follow-ups, I think it would be good if we could > review any pending patches before the release. We could pick some > cutoff date and say that any patch before that date is eligible for > holding up the release, provided it is pinged in a timely way. It would seem indeed fair that all patches sent prior to a cut-off date have a chance to be reviewed before we branch. Thinking out loud, this means the following requirements: (a) verifying that the active reviewers are OK with that; (b) determining a cut-off date; (c) establish the list of patches that still need to be reviewed. With the current patch submission system, establishing the list of patches (c) seems difficult. Is anyone able to build it without spending an unreasonable amount of time doing so? In terms of the patch reviews, assuming we have a patch list, I think the review process should include a yes/no decision regarding what to do wrt the release process. Either: - Delay branching until fixed; - Include change if ready before branching; - Allow branching if not ready, and then either: + block the release until fix backported; + review whether to backport if ready before release time - block change until branching (if, e.g. too risky). That way, after the first pass, we've already filtered the list down to the patches that are either safe-enough or release-critical. The balance we'll want to strike is between the list of changes we want causing a delay in the branching, vs the amount of time we're holding other changes that are deemed unsafed and would like to postpone after branching. One way to avoid the delay for risky changes is to branch now, and be fairly open with backporting. That's not the approach we've taken in the past, but that is still an option, if we want. It's more difficult to maintain quality on two active branches, IMO, so I tend to prefer the approach where we stabilize master first. -- Joel