From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14649 invoked by alias); 22 Jun 2018 18:22: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 14619 invoked by uid 89); 22 Jun 2018 18:22:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=people's, peoples, Rather, IPv4 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; Fri, 22 Jun 2018 18:22:43 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 96E6C56053; Fri, 22 Jun 2018 14:22:41 -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 vXccOBEf+JuD; Fri, 22 Jun 2018 14:22:41 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 7B93B56052; Fri, 22 Jun 2018 14:22:41 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E484984347; Fri, 22 Jun 2018 14:22:40 -0400 (EDT) Date: Fri, 22 Jun 2018 18:22:00 -0000 From: Joel Brobecker To: Sergio Durigan Junior Cc: gdb-patches@sourceware.org Subject: Re: GDB 8.2 branch 2018-06-22 Update Message-ID: <20180622182240.GB3143@adacore.com> References: <20180622140540.GC3128@adacore.com> <87fu1eep8o.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fu1eep8o.fsf@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2018-06/txt/msg00549.txt.bz2 Hi Sergio, > > * (SergioDJ) Implement IPv6 support for GDB/gdbserver > > > > From what I can tell, a v2 was sent, and a review done just > > a couple of days ago. Is that accurate? > > > > [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00384.html > > [v1] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00238.html > > Yes, that is accurate. I'm now working on addressing a few aspects of > the review, but it is still a bit unclear to me whether my new approach > will be accepted or whether Pedro's suggested approach will work without > problems. I'm doing some testing to determine what to do next. Thanks for the update. > I'd like to know: if, for some reason, I'm unable to get this patch > accepted until, say, next Thursday (June 28th), would it be OK to remove > it from the list of blockers, and to backport it to the branch later? > I'm asking because I don't want to be the one blocking the branching > from happening, since the IPv6 feature is not a major regression/problem > to be fixed anyway. It depends on how intrusive the patch is, so it's a judgement call. For patches that are really obviously safe, or for which we can say that they cannot affect anything but themselves, the decision is fairly easy. For other patches, we need to weigh the benefits vs the risk we are taking. One thing we could be doing is cut the branch, but then wait for the branch to contain the changes we want before we create the first pre-release. The pre-release tarballs are our last change for field testing before we issue the first release, and in the case of a riskier than usual patch, it can be one way to compromise. We've only done it once or twice, if memory serves, and the context was that there was a difficult bug deemed critical that needed time to be fixed. Rather than holding people's changes for master up while we spent time fixing master, we just branched, knowing that we would have to backport the fix before we could generate the first pre-release. Who decides? I tend to defer to the maintainers who approved the patch for master. But if, for some reason, the maintainer doesn't feel like they can decide on their own, I am always happy to take a look and provide my opinion on the matter -- it is just sometimes a bit more difficult for me to make a fair assessment, not being entirely familiar with the patch. Scanning through v2 of your patch, my first reaction is that it seems a bit risky to be backporting this to the branch, as it touches the IPv4 layer quite a bit; it might be a lot of mechanical changes, but what it shows is that it needs a careful analysis of the risk we are taking. Having reviewed the patches in more details already, Pedro might be better placed to let you know the changes of getting it in after the branch. You might also want to think about this another way: If you rush your changes now and then we discover a major and difficult-to-fix bug, it's less pressure to have to fix it on master, than it is to have to do an emergency fix on the branch, possibly followed by an emergency release... I say this not to discourage people, but to make sure that the extra motivation of making a release doesn't turn into an unnecessary constraint. -- Joel