Re: GDB 12.0.90 available for testing

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

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