From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93361 invoked by alias); 19 Feb 2017 13:48:21 -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 93336 invoked by uid 89); 19 Feb 2017 13:48:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=merit, H*i:sk:wwokk28, long-time, H*f:sk:wwokk28 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; Sun, 19 Feb 2017 13:48:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0720C28D3E; Sun, 19 Feb 2017 08:48:16 -0500 (EST) 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 lofaJ5iPqIWd; Sun, 19 Feb 2017 08:48:15 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6325C28D3B; Sun, 19 Feb 2017 08:48:15 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id A7BD2603C3; Sun, 19 Feb 2017 17:48:10 +0400 (RET) Date: Sun, 19 Feb 2017 13:48:00 -0000 From: Joel Brobecker To: Antoine Tremblay Cc: Yao Qi , "gdb-patches@sourceware.org" , Tom Tromey , Pedro Alves , Andreas Arnez Subject: Re: One month away from GDB 8.0 branching Message-ID: <20170219134810.ka23jtf7kchkwi74@adacore.com> References: <20170215035852.yzqw733mvnxigh2s@adacore.com> <20170217101157.4unltc3putfxtamj@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-08-21) X-SW-Source: 2017-02/txt/msg00510.txt.bz2 > I'm OK with that however I would like to understand the > release/regression process a bit better that's still a bit new to me. > > So this means that regressions do not carry over releases ? > > So if an issue is introduced like this one from 7.11 to 7.12 and we > notice it late, and release 7.12 with it, it's not considered a > regression anymore from 7.12 to 8.0 ? > > It's just considered a bug ? No rule is cast in stone. Indeed, the general idea is that, if we discover an issue in mast that's not in the latest release, these are considered blocking regressions by default. There have been cases in the past where we decided to release without the fix, and these are decided based on severity, difficulty to fix, expected fix date, etc. For other issues discovered on master, if the issue was introduced in a previous release, we tend to classify them as not-blocking by default, based on the idea that normally, severe issues tend to be discovered quickly, so even if we had missed it for the .0, we would have known about it for the .1. Also, if the bug was in a release already, doing another release with that bug shouldn't hurt (that is, would not make things worse). However, just as before, this is only a guideline, and we can review each bug on a case by case basis, and with sufficient merit, long-time bugs can still be classified as blocking. I should also add that blocking/non-blocking is just a decision process meant to guide the release process. Non-blocking does not mean that the next release will necessarily have the bug as well. It just indicates that we are not expecting to be waiting for those issues to be resolved before we release. Contributing a patch ahead of the release process would ensure that the issue gets fixed in the release. -- Joel