GDB 9.1 release: Start of stabilization period ?

GDB 9.1 release: Start of stabilization period ?

[Joel Brobecker]

Hi everyone,

Now that the 8.3.1 release is out, I think now is a good time to
prepare the 9.1 release. I looked at the gdb/NEWS file and it is
chockablock full of goodies!

At the moment, there aren't any issues in bugzilla that are marked
pending for GDB 9.1.

Are there any issues that people would like to be fixed, before
we release GDB 9.1? For those issues, it would be good to see whether
these are blocking issues prior to branching, or not.

In the meantime, while we start collecting the list of issues
we want to fix for 9.1, if there aren't any objection, I'd like us
to start a cooling period so as to stabilize GDB prior to branching.

Thank you!
-- 
Joel

Re: GDB 9.1 release: Start of stabilization period ?

[Christian Biesinger via gdb-patches]

HI Joel,

On Sat, Oct 12, 2019 at 3:19 PM Joel Brobecker <brobecker@adacore.com> wrote:
>
> Hi everyone,
>
> Now that the 8.3.1 release is out, I think now is a good time to
> prepare the 9.1 release. I looked at the gdb/NEWS file and it is
> chockablock full of goodies!
>
> At the moment, there aren't any issues in bugzilla that are marked
> pending for GDB 9.1.
>
> Are there any issues that people would like to be fixed, before
> we release GDB 9.1? For those issues, it would be good to see whether
> these are blocking issues prior to branching, or not.
>
> In the meantime, while we start collecting the list of issues
> we want to fix for 9.1, if there aren't any objection, I'd like us
> to start a cooling period so as to stabilize GDB prior to branching.

I'm not that familiar with the gdb release process, but there are two
changes that I was hoping could be part of the next release:
- The threaded symbol loading that tromey (and I) have been working on
- My patch here: https://sourceware.org/ml/gdb-patches/2019-10/msg00125.html

Thanks,
Christian

Re: GDB 9.1 release: Start of stabilization period ?

[Tom de Vries]

On 13-10-2019 03:18, Christian Biesinger via gdb-patches wrote:
> HI Joel,
> 
> On Sat, Oct 12, 2019 at 3:19 PM Joel Brobecker <brobecker@adacore.com> wrote:
>>
>> Hi everyone,
>>
>> Now that the 8.3.1 release is out, I think now is a good time to
>> prepare the 9.1 release. I looked at the gdb/NEWS file and it is
>> chockablock full of goodies!
>>
>> At the moment, there aren't any issues in bugzilla that are marked
>> pending for GDB 9.1.
>>
>> Are there any issues that people would like to be fixed, before
>> we release GDB 9.1? For those issues, it would be good to see whether
>> these are blocking issues prior to branching, or not.
>>
>> In the meantime, while we start collecting the list of issues
>> we want to fix for 9.1, if there aren't any objection, I'd like us
>> to start a cooling period so as to stabilize GDB prior to branching.
> 
> I'm not that familiar with the gdb release process,

Likewise.

Here's my wishlist:
- [gdb/tdep] Fix 'Unexpected register class' assert in
  amd64_push_arguments
  https://sourceware.org/ml/gdb-patches/2019-10/msg00293.html
- [gdb/tdep] Fix inferior call arg passing for amd64
  https://sourceware.org/ml/gdb-patches/2019-10/msg00307.html
- [gdb] Only force INTERP_CONSOLE ui_out for breakpoint commands in MI
  mode
  https://sourceware.org/ml/gdb-patches/2019-10/msg00099.html
- [gdb/symtab] Prefer var def over decl
  https://sourceware.org/ml/gdb-patches/2019-09/msg00161.html

Thanks,
- Tom

Re: GDB 9.1 release: Start of stabilization period ?

[Joel Brobecker]

> Here's my wishlist:
> - [gdb/tdep] Fix 'Unexpected register class' assert in
>   amd64_push_arguments
>   https://sourceware.org/ml/gdb-patches/2019-10/msg00293.html

Fixing asserts are always nice to have for releases :-)

> - [gdb/tdep] Fix inferior call arg passing for amd64
>   https://sourceware.org/ml/gdb-patches/2019-10/msg00307.html
> - [gdb] Only force INTERP_CONSOLE ui_out for breakpoint commands in MI
>   mode
>   https://sourceware.org/ml/gdb-patches/2019-10/msg00099.html
> - [gdb/symtab] Prefer var def over decl
>   https://sourceware.org/ml/gdb-patches/2019-09/msg00161.html

These look fine in principle as well.

I can't review the patches in detail, but I did noticed on the last
one that you're adding functions without adding documentation for them.

-- 
Joel

Re: GDB 9.1 release: Start of stabilization period ?

[Tom de Vries]

On 15-10-2019 17:20, Joel Brobecker wrote:
>> Here's my wishlist:
>> - [gdb/tdep] Fix 'Unexpected register class' assert in
>>   amd64_push_arguments
>>   https://sourceware.org/ml/gdb-patches/2019-10/msg00293.html
> 
> Fixing asserts are always nice to have for releases :-)
> 

Yeah :)

>> - [gdb/tdep] Fix inferior call arg passing for amd64
>>   https://sourceware.org/ml/gdb-patches/2019-10/msg00307.html
>> - [gdb] Only force INTERP_CONSOLE ui_out for breakpoint commands in MI
>>   mode
>>   https://sourceware.org/ml/gdb-patches/2019-10/msg00099.html
>> - [gdb/symtab] Prefer var def over decl
>>   https://sourceware.org/ml/gdb-patches/2019-09/msg00161.html
> 
> These look fine in principle as well.
> 
> I can't review the patches in detail, but I did noticed on the last
> one that you're adding functions without adding documentation for them.
> 

Correct, Andrew also noticed that, that was fixed already and
resubmitted using Gerrit.

Thanks,
- Tom

Re: GDB 9.1 release: Start of stabilization period ?

[Joel Brobecker]

> Correct, Andrew also noticed that, that was fixed already and
> resubmitted using Gerrit.

Gerrit... Awesome!

-- 
Joel

Re: GDB 9.1 release: Start of stabilization period ?

[Joel Brobecker]

> I'm not that familiar with the gdb release process, but there are two
> changes that I was hoping could be part of the next release:
> - The threaded symbol loading that tromey (and I) have been working on

Could you send a link to that discussion? I'd like to take a look to
evaluate the risk in terms of stabilization...

> - My patch here: https://sourceware.org/ml/gdb-patches/2019-10/msg00125.html

This one looks fine.

-- 
Joel

Re: GDB 9.1 release: Start of stabilization period ?

[Philippe Waroquiers]

On Sat, 2019-10-12 at 15:19 -0400, Joel Brobecker wrote:
> Hi everyone,
> 
> Now that the 8.3.1 release is out, I think now is a good time to
> prepare the 9.1 release. I looked at the gdb/NEWS file and it is
> chockablock full of goodies!
> 
> At the moment, there aren't any issues in bugzilla that are marked
> pending for GDB 9.1.
> 
> Are there any issues that people would like to be fixed, before
> we release GDB 9.1? For those issues, it would be good to see whether
> these are blocking issues prior to branching, or not.
> 
> In the meantime, while we start collecting the list of issues
> we want to fix for 9.1, if there aren't any objection, I'd like us
> to start a cooling period so as to stabilize GDB prior to branching.

Here are the patches sent for review
(by order of first submission, but pointing at the last exchange):

RFC Have an option to tell GDB to detect and possibly handle mismatched exec-files
https://sourceware.org/ml/gdb-patches/2019-09/msg00580.html

Convenience functions $_gdb_setting/$_gdb_setting_str
https://sourceware.org/ml/gdb-patches/2019-09/msg00581.html

Allow the user to define default leading args for commands and aliases
https://sourceware.org/ml/gdb-patches/2019-09/msg00583.html

Implement 'print -raw-values' and 'set print raw-values on|off'
https://sourceware.org/ml/gdb-patches/2019-09/msg00582.html

More flexible user-defined commands prefixing and naming.
https://sourceware.org/ml/gdb-patches/2019-09/msg00588.html


And here is the advocacy to include them ...

The first one fixes an annoying GDB behavior.

I think the second one is now ready to push.

The third and fourth are useful additions or complements
to the GDB 9.1 'with' and 'option framework' functionalities.

Assuming that with the stabilisation period, there is more review
bandwidth, then the last one is nice to have :).

Thanks
Philippe

Re: GDB 9.1 release: Start of stabilization period ?

[Joel Brobecker]

Hi Philippe,

Based on the current overall feedback, I think you'll manage to get
if not all, probably some of the changes you propose below.
I'll keep them in my list of items to watch out for, but
see also my comments below:

> Here are the patches sent for review
> (by order of first submission, but pointing at the last exchange):
> 
> RFC Have an option to tell GDB to detect and possibly handle mismatched exec-files
> https://sourceware.org/ml/gdb-patches/2019-09/msg00580.html

We can try to keep this one in the list, but I wouldn't mark it
as absolutely critical for the release.

> Convenience functions $_gdb_setting/$_gdb_setting_str
> https://sourceware.org/ml/gdb-patches/2019-09/msg00581.html

Same idea as above, except you are saying that it's ready to push.
Given what we have in the list, and the general proposal, I think
you'll manage to get this one in on time. But I propose we allow
ourselves to skip it if it delays the release process by an unreasonable
amount of time for whatever reason.

> Allow the user to define default leading args for commands and aliases
> https://sourceware.org/ml/gdb-patches/2019-09/msg00583.html
> 
> Implement 'print -raw-values' and 'set print raw-values on|off'
> https://sourceware.org/ml/gdb-patches/2019-09/msg00582.html

> More flexible user-defined commands prefixing and naming.
> https://sourceware.org/ml/gdb-patches/2019-09/msg00588.html

These is the kind of change where I think we benefit from not rushing
too much. If it's ready, then great, let's have it. On the other end,
it's really nice to have new features have an "observation period"
in master before they make it to a release. That way, if we discover
some weaknesses while using it in master, we have a chance to adjust
without having to worry about user-compatibility.

The story would be a bit different if you told me that a feature
we just added is severly limited without it, but from what I understand,
this is not the case.
Same here.

> And here is the advocacy to include them ...
> 
> The first one fixes an annoying GDB behavior.
> 
> I think the second one is now ready to push.
> 
> The third and fourth are useful additions or complements
> to the GDB 9.1 'with' and 'option framework' functionalities.
> 
> Assuming that with the stabilisation period, there is more review
> bandwidth, then the last one is nice to have :).
> 
> Thanks
> Philippe
> 

-- 
Joel

Re: GDB 9.1 release: Start of stabilization period ?

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> Are there any issues that people would like to be fixed, before
Joel> we release GDB 9.1?

Based on the other follow-ups, I think it would be good if we could
review any pending patches before the release.  We could pick some
cutoff date and say that any patch before that date is eligible for
holding up the release, provided it is pinged in a timely way.


Another question I have is whether we want to try to finish the "move
gdbserver" project.  The first step (moving gnulib) is in, but recall
that this broke in-tree builds -- which would be the major reason to
wait for this.  A couple subsequent steps (moving readline and moving
gdbsupport) have been submitted, but the final step has not.

Tom

Re: GDB 9.1 release: Start of stabilization period ?

[Joel Brobecker]

> Another question I have is whether we want to try to finish the "move
> gdbserver" project.  The first step (moving gnulib) is in, but recall
> that this broke in-tree builds -- which would be the major reason to
> wait for this.  A couple subsequent steps (moving readline and moving
> gdbsupport) have been submitted, but the final step has not.

In my opinion, this is the type of change that would benefit from
being done early in the development cycle compared to just before
branching. But, if there is an imperative reason why this should be
part of the next release cycle, then we can decide that we want
to wait for it first.

> Based on the other follow-ups, I think it would be good if we could
> review any pending patches before the release.  We could pick some
> cutoff date and say that any patch before that date is eligible for
> holding up the release, provided it is pinged in a timely way.

It would seem indeed fair that all patches sent prior to a cut-off
date have a chance to be reviewed before we branch. Thinking out loud,
this means the following requirements:

   (a) verifying that the active reviewers are OK with that;
   (b) determining a cut-off date;
   (c) establish the list of patches that still need to be reviewed.

With the current patch submission system, establishing the list of
patches (c) seems difficult. Is anyone able to build it without
spending an unreasonable amount of time doing so?

In terms of the patch reviews, assuming we have a patch list,
I think the review process should include a yes/no decision regarding
what to do wrt the release process. Either:
  - Delay branching until fixed;
  - Include change if ready before branching;
  - Allow branching if not ready, and then either:
      + block the release until fix backported;
      + review whether to backport if ready before release time
  - block change until branching (if, e.g. too risky).

That way, after the first pass, we've already filtered the list
down to the patches that are either safe-enough or release-critical.

The balance we'll want to strike is between the list of changes
we want causing a delay in the branching, vs the amount of time
we're holding other changes that are deemed unsafed and would
like to postpone after branching. One way to avoid the delay for
risky changes is to branch now, and be fairly open with backporting.
That's not the approach we've taken in the past, but that is still
an option, if we want. It's more difficult to maintain quality
on two active branches, IMO, so I tend to prefer the approach where
we stabilize master first.

-- 
Joel