From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 3B8C43858D28 for ; Thu, 7 Apr 2022 18:00:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B8C43858D28 Received: by mail-pf1-x436.google.com with SMTP id b15so6154907pfm.5 for ; Thu, 07 Apr 2022 11:00:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=E4q9OJd3fk3pG/tGEnL6BoG3WAZXGFDWagzejMy0Lnk=; b=IIs0iiE+rpyWReBbSJyL93NqZLDNBfPVbIA2kXlTTMHyrMblx4yHJmzjCgNMTRh7UR IuotMegLMb6is295gW6NLO3Ach3anp1p2DpFTa6O6h9lbnOEOZbYgxKrfLTCpw2b9hkS yPbbfh7JK4ssWrMeX3h1Gsbk67v/6D+DqZIvgt0rmpXU8qSKfuE/Occal+V80Mm/OR5S 4usNwqLE9pFUnHVl8M+Eat6i/vdfXfemwHyHxlDJBFDCywbKT745Bc5k5jhWRMB3Hq3U zic3zevx4EepimmnZZCmC2MLR59gODfThsh1AH/ENOFckMH0UETnaH1NI6sf5eS1qBF2 Sm8A== X-Gm-Message-State: AOAM531bd1d1ytTAG7yEEfW+ZsRrwjvteWCD928d82bF+ekpObjgAdkN JY9qkwKX3Wa1/22H6c6W3zXAExRkDGI+ X-Google-Smtp-Source: ABdhPJxxny60axAVN8SfPJYiZ6S79RXEMdSUHchbK0ta5FH/Kfr5qCSycYg669WxiW1PpvI0Dbn1BA== X-Received: by 2002:a63:5522:0:b0:398:f8a1:c8bd with SMTP id j34-20020a635522000000b00398f8a1c8bdmr12167201pgb.118.1649354439039; Thu, 07 Apr 2022 11:00:39 -0700 (PDT) Received: from takamaka.home ([184.69.131.86]) by smtp.gmail.com with ESMTPSA id d5-20020a056a0010c500b004faee9887ccsm23479460pfu.64.2022.04.07.11.00.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 11:00:38 -0700 (PDT) Received: by takamaka.home (Postfix, from userid 1000) id 423E5A7574; Thu, 7 Apr 2022 11:00:37 -0700 (PDT) Date: Thu, 7 Apr 2022 11:00:37 -0700 From: Joel Brobecker To: Eli Zaretskii Cc: Tom Tromey , gdb-patches@sourceware.org, brobecker@adacore.com Subject: Re: GDB 12.0.90 available for testing Message-ID: References: <20220320055815.2A90FA4D6C@takamaka.home> <83v8w0ag5j.fsf@gnu.org> <83tubkadx4.fsf@gnu.org> <87ee28anbg.fsf@tromey.com> <83pmlsc1pj.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83pmlsc1pj.fsf@gnu.org> X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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:00:41 -0000 > > 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'm not sure whether we want to attempt an update on the GDB 12 branch. > > No, I don't think we should. It's too late for GDB 12, IMO. Agreed. On the branch, we should make local and targeted changes instead. -- Joel