From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Cc: Tom Tromey , gdb-patches@sourceware.org References: <20220320055815.2A90FA4D6C@takamaka.home> <83v8w0ag5j.fsf@gnu.org> <83tubkadx4.fsf@gnu.org> <87ee28anbg.fsf@tromey.com> <83pmlsc1pj.fsf@gnu.org> From: Simon Marchi 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-Spam-Status: No, score=-3034.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 07 Apr 2022 18:04:51 -0000 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