From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39182 invoked by alias); 22 Jun 2018 20:41:33 -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 39164 invoked by uid 89); 22 Jun 2018 20:41:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Who, weekend, crazy X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Jun 2018 20:41:31 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB34E4023132; Fri, 22 Jun 2018 20:41:29 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 96F7F2156889; Fri, 22 Jun 2018 20:41:29 +0000 (UTC) From: Sergio Durigan Junior To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: GDB 8.2 branch 2018-06-22 Update References: <20180622140540.GC3128@adacore.com> <87fu1eep8o.fsf@redhat.com> <20180622182240.GB3143@adacore.com> Date: Fri, 22 Jun 2018 20:41:00 -0000 In-Reply-To: <20180622182240.GB3143@adacore.com> (Joel Brobecker's message of "Fri, 22 Jun 2018 14:22:40 -0400") Message-ID: <877emqeepy.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00551.txt.bz2 On Friday, June 22 2018, Joel Brobecker wrote: >> 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. Thanks for the throrough explanation, it's always good to understand more about the whole process. I agree with you: the patch is a bit risky, indeed. Even though I'm trying to extend the existing tests and make sure that it works as it should, there's always the possibility of making a mistake, especially if we rush things. > 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. You're absolutely right. I've been thinking about that myself, and that's why I decided to send the e-mail and ask more details about the process of backporting. Curiously, we at Red Hat have had to discuss a very similar situation involving this same patch, and we also decided to postpone including it in a next RHEL GDB release for the same reason. Having said all that, I would like to request the removal of the IPv6 patch from the list of blocking features for the branch. I think it's better for Pedro as well, because this way he doesn't have to try to review things like crazy before next weekend. Thanks a lot, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/