From: Joel Brobecker via Gdb <gdb@sourceware.org>
To: Luis Machado <luis.machado@arm.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
Luis Machado via Gdb <gdb@sourceware.org>,
Andrew Burgess <aburgess@redhat.com>
Subject: Re: Backporting minor fix to older gdb releases
Date: Mon, 20 Mar 2023 08:18:13 +0400 [thread overview]
Message-ID: <ZBfehantRvjEkDAV@adacore.com> (raw)
In-Reply-To: <58337751-da16-58e1-0327-1e452472decd@arm.com>
> > FWIW, there is no real policy that I know of.
> >
> > We have been known to accept patches on release branches past the .2
> > release. It's been very rare, though. In all cases, the push was done
> > with the understanding that there would likely not be another official
> > release off that branch, so that was purely for the benefit of people
> > who wanted to build from the HEAD of a release branch rather than from
> > an official release.
> >
> > Whether we should be doing it in this case, I don't have a strong
> > opinion. I think Andrew is making good points, and I'm wondering
> > whether it will actually serve anyone if we backport the patches.
> > On the other hand, are the patches extra safe? If they are, perhaps
> > in the spirit of not standing in the way of someone willing to make
> > it better for others...
> >
>
> All reasonable points, I agree.
>
> The patch (a single one) is mostly trivial reordering of code to fix a
> pseudo-register number that we get wrong for the pauth feature. It
> helps in that it allows people to use gdb 9/10/11/12 with a new qemu.
> Otherwise those gdb's will just crash on connection, with no way
> around it.
This part I understood. The part I wasn't sure about is whether
there was any known entity that would pick the branch update up,
and rebuild with it.
Nevertheless, this is not critical at all. As long as the patch
is extra safe (which it looks like it can't possibly cause things
to be worse, except in the pauth case which is already crashing),
I don't see a reason why we should block the patch's inclusion
in our older branches. You can go right ahead.
--
Joel
next prev parent reply other threads:[~2023-03-20 4:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 23:18 Luis Machado via Gdb
2023-03-15 11:33 ` Andrew Burgess via Gdb
2023-03-15 12:26 ` Luis Machado via Gdb
2023-03-15 13:11 ` Joel Brobecker via Gdb
2023-03-15 13:45 ` Luis Machado via Gdb
2023-03-20 4:18 ` Joel Brobecker via Gdb [this message]
2023-03-22 9:57 ` Luis Machado via Gdb
2023-04-11 6:04 ` Luis Machado via Gdb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZBfehantRvjEkDAV@adacore.com \
--to=gdb@sourceware.org \
--cc=aburgess@redhat.com \
--cc=brobecker@adacore.com \
--cc=luis.machado@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox