GDB 13.2 and GDB 14 releases...

GDB 13.2 and GDB 14 releases...

[Joel Brobecker]

Hi Team,

GDB 13.2 Release:
=================

It's been a little over 2 months since we released GDB 13.1, so
I thought I'd start investigating a possible GDB 13.2 release,
roughly a month from now. I looked at the gdb-13-branch, and
we have a total of 5 changes, all of them sufficiently important
IMO to justify a .2 release. So let's do it, and let's target
end of May for it.

If you guys know of any problem that you think should be fixed in
GDB 13.2, and therefore should block its release, please create
a Bugzilla PR for it, and then set its Target Milestone to 13.2.

As a reminder also: Now that the .1 release has been made, *all*
changes to the gdb-13-branch should be documented via a Buzilla PR.
This is to ensure that, come the time to make the release, the
announcement can include the list of changes brought by the release,
and the links to the corresponding PRs.

GDB 14.1 Branching and Release
==============================

Normally, my default approach is to start talking about the next
major release as soon as the previous .2 release is out. The idea
is to give ourselve 3 months or so to prepare for it, branch and
then release, so as to try to follow a schedule of one major release
every 6 months.

In this case, I think it's too early to tell. I've looked at the NEWS
file, and while there are a number of nice new features, maybe we might
want to wait a little longer to see if we can pack this release a little
more.

Cheers,
-- 
Joel

Re: GDB 13.2 and GDB 14 releases...

[Simon Marchi]

On 4/29/23 16:15, Joel Brobecker via Gdb-patches wrote:
> GDB 14.1 Branching and Release
> ==============================
> 
> Normally, my default approach is to start talking about the next
> major release as soon as the previous .2 release is out. The idea
> is to give ourselve 3 months or so to prepare for it, branch and
> then release, so as to try to follow a schedule of one major release
> every 6 months.
> 
> In this case, I think it's too early to tell. I've looked at the NEWS
> file, and while there are a number of nice new features, maybe we might
> want to wait a little longer to see if we can pack this release a little
> more.

IMO, it's better to make regular releases than waiting to have a certain
amount of changes.  The changes currently in master might not look
important to me, but maybe someone else is eagerly waiting for a
specific fix or feature to be officially released.

Simon

Re: GDB 13.2 and GDB 14 releases...

[Joel Brobecker]

Hi Simon,

> IMO, it's better to make regular releases than waiting to have a certain
> amount of changes.  The changes currently in master might not look
> important to me, but maybe someone else is eagerly waiting for a
> specific fix or feature to be officially released.

Thanks for the suggestion. That makes sense too. Do people want us
to switch to this kind of approach?

-- 
Joel

Re: GDB 13.2 and GDB 14 releases...

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]


Joel Brobecker via Gdb-patches <gdb-patches@sourceware.org> writes:

> Hi Simon,
>
>> IMO, it's better to make regular releases than waiting to have a certain
>> amount of changes.  The changes currently in master might not look
>> important to me, but maybe someone else is eagerly waiting for a
>> specific fix or feature to be officially released.
>
> Thanks for the suggestion. That makes sense too. Do people want us
> to switch to this kind of approach?

Yeah, I'd definitely appreciate it for Gentoo. In fact, when you sent
the first email in this thread, I'd just been wondering if I should ask
about a point release at least.

Distros in general don't need a release to be action-packed (crammed
full of features), it's better that we get bug fixes out faster and
not have to worry about cherry-picking ourselves. It also makes
debugging any regressions a lot easier if the delta is a bit smaller ;)

I've CC'd marcan as well because he recently had some frustration
working on Asahi Linux when it turned out something had been fixed in
master a good while ago but hadn't propagated into a release.

The only disadvantage I see is if there's too much work to cut a release. But
the fix to that is to make releases easier, I think.

best,
sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: GDB 13.2 and GDB 14 releases...

[Hector Martin]

On 02/05/2023 00.15, Sam James wrote:
> 
> Joel Brobecker via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>> Hi Simon,
>>
>>> IMO, it's better to make regular releases than waiting to have a certain
>>> amount of changes.  The changes currently in master might not look
>>> important to me, but maybe someone else is eagerly waiting for a
>>> specific fix or feature to be officially released.
>>
>> Thanks for the suggestion. That makes sense too. Do people want us
>> to switch to this kind of approach?
> 
> Yeah, I'd definitely appreciate it for Gentoo. In fact, when you sent
> the first email in this thread, I'd just been wondering if I should ask
> about a point release at least.
> 
> Distros in general don't need a release to be action-packed (crammed
> full of features), it's better that we get bug fixes out faster and
> not have to worry about cherry-picking ourselves. It also makes
> debugging any regressions a lot easier if the delta is a bit smaller ;)
> 
> I've CC'd marcan as well because he recently had some frustration
> working on Asahi Linux when it turned out something had been fixed in
> master a good while ago but hadn't propagated into a release.

Yup. The state of affairs on Apple machines right now is that I am
learning lldb, because gdb is completely broken and crashes immediately
on `run`. This was a 13.1 regression that was fixed upstream a month
ago, but there has been no point fix release since then.

I don't think it's really reasonable to expect downstream distros to
patch software to make it work *at all*. Stuff like this should trigger
a point bugfix release.

- Hector

Re: GDB 13.2 and GDB 14 releases...

[Simon Marchi]

On 5/1/23 10:58, Joel Brobecker wrote:
> Hi Simon,
> 
>> IMO, it's better to make regular releases than waiting to have a certain
>> amount of changes.  The changes currently in master might not look
>> important to me, but maybe someone else is eagerly waiting for a
>> specific fix or feature to be officially released.
> 
> Thanks for the suggestion. That makes sense too. Do people want us
> to switch to this kind of approach?
> 

I think what you are already doing (roughly every 6 months) is good.
I'm just saying that it's fine to release even if there's not an
overwhelming amount of new stuff.


Simon

Re: GDB 13.2 and GDB 14 releases...

[Luis Machado]

On 5/1/23 15:58, Joel Brobecker via Gdb-patches wrote:
> Hi Simon,
> 
>> IMO, it's better to make regular releases than waiting to have a certain
>> amount of changes.  The changes currently in master might not look
>> important to me, but maybe someone else is eagerly waiting for a
>> specific fix or feature to be officially released.
> 
> Thanks for the suggestion. That makes sense too. Do people want us
> to switch to this kind of approach?
> 

Sounds good to me as well.

Re: GDB 13.2 and GDB 14 releases...

[John Baldwin]

On 5/1/23 6:37 AM, Simon Marchi via Gdb-patches wrote:
> On 4/29/23 16:15, Joel Brobecker via Gdb-patches wrote:
>> GDB 14.1 Branching and Release
>> ==============================
>>
>> Normally, my default approach is to start talking about the next
>> major release as soon as the previous .2 release is out. The idea
>> is to give ourselve 3 months or so to prepare for it, branch and
>> then release, so as to try to follow a schedule of one major release
>> every 6 months.
>>
>> In this case, I think it's too early to tell. I've looked at the NEWS
>> file, and while there are a number of nice new features, maybe we might
>> want to wait a little longer to see if we can pack this release a little
>> more.
> 
> IMO, it's better to make regular releases than waiting to have a certain
> amount of changes.  The changes currently in master might not look
> important to me, but maybe someone else is eagerly waiting for a
> specific fix or feature to be officially released.

I'm also a fan of time-based release schedules.

-- 
John Baldwin

Re: GDB 13.2 and GDB 14 releases...

[Luis Machado]

On 4/29/23 21:15, Joel Brobecker via Gdb-patches wrote:
> Hi Team,
> 
> GDB 13.2 Release:
> =================
> 
> It's been a little over 2 months since we released GDB 13.1, so
> I thought I'd start investigating a possible GDB 13.2 release,
> roughly a month from now. I looked at the gdb-13-branch, and
> we have a total of 5 changes, all of them sufficiently important
> IMO to justify a .2 release. So let's do it, and let's target
> end of May for it.
> 
> If you guys know of any problem that you think should be fixed in
> GDB 13.2, and therefore should block its release, please create
> a Bugzilla PR for it, and then set its Target Milestone to 13.2.
> 
> As a reminder also: Now that the .1 release has been made, *all*
> changes to the gdb-13-branch should be documented via a Buzilla PR.
> This is to ensure that, come the time to make the release, the
> announcement can include the list of changes brought by the release,
> and the links to the corresponding PRs.
> 
> GDB 14.1 Branching and Release
> ==============================
> 
> Normally, my default approach is to start talking about the next
> major release as soon as the previous .2 release is out. The idea
> is to give ourselve 3 months or so to prepare for it, branch and
> then release, so as to try to follow a schedule of one major release
> every 6 months.
> 
> In this case, I think it's too early to tell. I've looked at the NEWS
> file, and while there are a number of nice new features, maybe we might
> want to wait a little longer to see if we can pack this release a little
> more.

Maybe so. I'd like to get the base SME functionality for AArch64, and it is still
under review at this point. Hopefully that can make it to GDB 14.

> 
> Cheers,