From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sObnIdYnT2JgcwAAWB0awg (envelope-from ) for ; Thu, 07 Apr 2022 14:05:10 -0400 Received: by simark.ca (Postfix, from userid 112) id 8158F1F344; Thu, 7 Apr 2022 14:05:10 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id ED4541E787 for ; Thu, 7 Apr 2022 14:05:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A77693857805 for ; Thu, 7 Apr 2022 18:05:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A77693857805 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1649354709; bh=buvmDvgz6gpinRnmA/sD/Fxwi+atgMWCAoW7dpGMi8o=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=EHKuzxIocccZpmhyJcvKjvGl/SgByoh1fpY+/xJrBCHZ9ztS2bBDu2AvIy90yAOxF E0Acwl/uQYE6fqH1zS8gfJOPwp1xuV8idxlYJ2lEJau4AJ7P8ZALH2eVOTSzyeJUNg pS98SJi5q/XA34TMipsrDUPe2U5s0b1yYa/HsCoU= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id DF5043858D28 for ; Thu, 7 Apr 2022 18:04:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF5043858D28 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 237I4eb2023248 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Apr 2022 14:04:44 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 237I4eb2023248 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id D1E9D1E787; Thu, 7 Apr 2022 14:04:39 -0400 (EDT) Message-ID: <48afa691-d3d5-e55e-29e6-cdfa2c5cc149@polymtl.ca> Date: Thu, 7 Apr 2022 14:04:39 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: GDB 12.0.90 available for testing Content-Language: en-US To: Joel Brobecker , Eli Zaretskii References: <20220320055815.2A90FA4D6C@takamaka.home> <83v8w0ag5j.fsf@gnu.org> <83tubkadx4.fsf@gnu.org> <87ee28anbg.fsf@tromey.com> <83pmlsc1pj.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 7 Apr 2022 18:04:40 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: Tom Tromey , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-04-07 14:00, Joel Brobecker via Gdb-patches wrote: >>> If there's a particular gnulib import that's needed, I'm happy to do it. >>> I'd just need to know the revision. >> >> It isn't a single update. I identified at least 2, maybe 3 changes >> Gnulib installed based on my reports of problems found in GDB 11. >> >>> Or, maybe we should just adopt a policy of doing an import from >>> gnulib HEAD on trunk after a release branch is made? >> >> IMO, it would be best. But that's not my call, especially since Joel >> says there seems to be a policy about that. > > There isn't really a policy per se. It's just my understanding > that we currently do not have a process where updates are brought in > on a regular basis -- we stay with a given version until someone > who needs an upgrade send a patch to make the changes he needs. > > I agree that having a policy can be helpful. Tom's proposal sounds > fine to me, especially since we have someone who kindly volunteers > to make it happen, at least this time around. > > Meanwhile, even if the group decides to reject this as a policy, > I don't think we'll reject patches that upgrade our import of gnulib, > as this is something we're bound to do the next time we need some > fixes made upstream. So, anyone willing to do an update can propose it, > whether we have a policy or not, and it'll be a useful change on its > own right, IMO. I think that systematically upgrading right after a branch creation is a good idea. It is less risky for us, since the following release to use that code is quite far away. And it is a good idea to consume the new gnulib code as early as possible, to weed out and report any problem upstream. It is better to report problems early than reporting them two years after the change has been made. Simon