One month away from GDB 8.0 branching

One month away from GDB 8.0 branching

[Joel Brobecker]

Hello everyone,

We're now one month away from our planned branching date for 8.0.
The wiki page we'll use to track all issues related to this release
is: https://sourceware.org/gdb/wiki/GDB_8.0_Release

If you know of some issues that you think should be resolved before
we create the 8.0 branch, please let us know so we can document them
in the wiki page.

If you have some issues that you think are not blocking for the branch
creation, but should be blocking for the release, please let us know
as well, so we can decide what to do. At the procedural level, we will
have two options:

  * If a PR was already created for it, just mark the "Target Milestone"
    to 8.0; or

  * If not, add an entry in the wiki instead.

Currently, we have 2 PRs marked for 8.0:

    19426  in non-stop mode, gdb should sometimes select the stopping thread

        Currently not assigned, but looks active between Pedro and Tom.
        Not sure it is blocking, though, so I asked for confirmation.

    21162  GDB internal error with unbounded array typecast expression

        An internal-error, so fairly serious.  If this is a regression,
        then this will indeed be blocking. This is currently unassigned,
        is anyone investigating this (Andreas?)

Thanks!

-- 
Joel

Re: One month away from GDB 8.0 branching

[Antoine Tremblay]

Joel Brobecker writes:

> Hello everyone,
>
> We're now one month away from our planned branching date for 8.0.
> The wiki page we'll use to track all issues related to this release
> is: https://sourceware.org/gdb/wiki/GDB_8.0_Release
>
> If you know of some issues that you think should be resolved before
> we create the 8.0 branch, please let us know so we can document them
> in the wiki page.
>
> If you have some issues that you think are not blocking for the branch
> creation, but should be blocking for the release, please let us know
> as well, so we can decide what to do. At the procedural level, we will
> have two options:
>

I created a PR for this issue :
https://sourceware.org/bugzilla/show_bug.cgi?id=21169

I've marked it Target Milestone 8.0

But the wiki doesn't work for me, I was sure I had an account but can't
login, invalid l/p, and I can't create an account I get : 
503 You triggered the wiki's surge protection , on my first try....

If someone would kindly add it to the maybe for release section it would
be nice.

Thanks,
Antoine

Re: One month away from GDB 8.0 branching

[Joel Brobecker]

> I created a PR for this issue :
> https://sourceware.org/bugzilla/show_bug.cgi?id=21169
> 
> I've marked it Target Milestone 8.0

Thanks. And thanks for mentioning that this is indeed a regression;
this helps confirm that this is indeed blocking for 8.0.

> But the wiki doesn't work for me, I was sure I had an account but can't
> login, invalid l/p, and I can't create an account I get : 
> 503 You triggered the wiki's surge protection , on my first try....
> 
> If someone would kindly add it to the maybe for release section it would
> be nice.

Do you have reasons to believe that we should not be creating
the branch until this is fixed? If yes, then I'll add it to
the wiki, no problem. If we can create the branch, and fix the
issue on the branch later on, then adding it to the wiki is
unnecessary (the wiki is only for those who prefer that option
over creating a PR).

Thanks!
-- 
Joel

Re: One month away from GDB 8.0 branching

[Antoine Tremblay]

Joel Brobecker writes:

>> But the wiki doesn't work for me, I was sure I had an account but can't
>> login, invalid l/p, and I can't create an account I get : 
>> 503 You triggered the wiki's surge protection , on my first try....
>> 
>> If someone would kindly add it to the maybe for release section it would
>> be nice.
>
> Do you have reasons to believe that we should not be creating
> the branch until this is fixed?

No we can create the branch.

>If yes, then I'll add it to
> the wiki, no problem. If we can create the branch, and fix the
> issue on the branch later on, then adding it to the wiki is
> unnecessary (the wiki is only for those who prefer that option
> over creating a PR).
>

OK, np then, thanks!

Re: One month away from GDB 8.0 branching

[Yao Qi]

On Thu, Feb 16, 2017 at 12:23 AM, Antoine Tremblay
<antoine.tremblay@ericsson.com> wrote:
>
> I created a PR for this issue :
> https://sourceware.org/bugzilla/show_bug.cgi?id=21169
>
> I've marked it Target Milestone 8.0
>

I prefer to fixing this issue in 8.0 too, but to be clear, this is a
7.11 -> 7.12 regression.
We changed GDBserver to single step over breakpoint on July 2016, but 7.12 was
released on Oct 2016.

-- 
Yao (齐尧)

Re: One month away from GDB 8.0 branching

[Joel Brobecker]

> > I created a PR for this issue :
> > https://sourceware.org/bugzilla/show_bug.cgi?id=21169
> >
> > I've marked it Target Milestone 8.0
> >
> 
> I prefer to fixing this issue in 8.0 too, but to be clear, this is a
> 7.11 -> 7.12 regression.
> We changed GDBserver to single step over breakpoint on July 2016, but
> 7.12 was released on Oct 2016.

That's a very useful piece of information. Thanks, Yao.

Normally, the fact that this isn't a regression is a strong
indicator that we don't need to block a release pending resolution.
In this particular case, given the fairly bad effect on the debugging
session, and the fact that the regression was introduced in our last
branch, I propose a compromise. We leave it like that for now, and
will potentially delay the 8.0 release a bit waiting for the fix,
provided that some one is working on it, and tells us he is close
to having it. And, come release time, if we the fix is delayed
to much, or there isn't any news about it, we'll set change
the target milestone to 8.0.1 and try the same approach (wait a bit
if there are chances we might get the fix soon).

Does this sound OK?

-- 
Joel

Re: One month away from GDB 8.0 branching

[Antoine Tremblay]

Joel Brobecker writes:

>> > I created a PR for this issue :
>> > https://sourceware.org/bugzilla/show_bug.cgi?id=21169
>> >
>> > I've marked it Target Milestone 8.0
>> >
>>
>> I prefer to fixing this issue in 8.0 too, but to be clear, this is a
>> 7.11 -> 7.12 regression.
>> We changed GDBserver to single step over breakpoint on July 2016, but
>> 7.12 was released on Oct 2016.
>
> That's a very useful piece of information. Thanks, Yao.
>
> Normally, the fact that this isn't a regression is a strong
> indicator that we don't need to block a release pending resolution.
> In this particular case, given the fairly bad effect on the debugging
> session, and the fact that the regression was introduced in our last
> branch, I propose a compromise. We leave it like that for now, and
> will potentially delay the 8.0 release a bit waiting for the fix,
> provided that some one is working on it, and tells us he is close
> to having it. And, come release time, if we the fix is delayed
> to much, or there isn't any news about it, we'll set change
> the target milestone to 8.0.1 and try the same approach (wait a bit
> if there are chances we might get the fix soon).


I'm OK with that however I would like to understand the
release/regression process a bit better that's still a bit new to me.

So this means that regressions do not carry over releases ?

So if an issue is introduced like this one from 7.11 to 7.12 and we
notice it late, and release 7.12 with it, it's not considered a
regression anymore from 7.12 to 8.0 ?

It's just considered a bug ?

Thanks,
Antoine

Re: One month away from GDB 8.0 branching

[Joel Brobecker]

> I'm OK with that however I would like to understand the
> release/regression process a bit better that's still a bit new to me.
> 
> So this means that regressions do not carry over releases ?
> 
> So if an issue is introduced like this one from 7.11 to 7.12 and we
> notice it late, and release 7.12 with it, it's not considered a
> regression anymore from 7.12 to 8.0 ?
> 
> It's just considered a bug ?

No rule is cast in stone. Indeed, the general idea is that,
if we discover an issue in mast that's not in the latest release,
these are considered blocking regressions by default. There have
been cases in the past where we decided to release without the fix,
and these are decided based on severity, difficulty to fix, expected
fix date, etc.

For other issues discovered on master, if the issue was introduced
in a previous release, we tend to classify them as not-blocking
by default, based on the idea that normally, severe issues tend
to be discovered quickly, so even if we had missed it for the .0,
we would have known about it for the .1. Also, if the bug was
in a release already, doing another release with that bug shouldn't
hurt (that is, would not make things worse). However, just as before,
this is only a guideline, and we can review each bug on a case by
case basis, and with sufficient merit, long-time bugs can still be
classified as blocking.

I should also add that blocking/non-blocking is just a decision
process meant to guide the release process. Non-blocking does not
mean that the next release will necessarily have the bug as well.
It just indicates that we are not expecting to be waiting for
those issues to be resolved before we release. Contributing a patch
ahead of the release process would ensure that the issue gets fixed
in the release.

-- 
Joel

Re: One month away from GDB 8.0 branching

[Antoine Tremblay]

Joel Brobecker writes:

>> I'm OK with that however I would like to understand the
>> release/regression process a bit better that's still a bit new to me.
>> 
>> So this means that regressions do not carry over releases ?
>> 
>> So if an issue is introduced like this one from 7.11 to 7.12 and we
>> notice it late, and release 7.12 with it, it's not considered a
>> regression anymore from 7.12 to 8.0 ?
>> 
>> It's just considered a bug ?
>
> No rule is cast in stone. Indeed, the general idea is that,
> if we discover an issue in mast that's not in the latest release,
> these are considered blocking regressions by default. There have
> been cases in the past where we decided to release without the fix,
> and these are decided based on severity, difficulty to fix, expected
> fix date, etc.
>
> For other issues discovered on master, if the issue was introduced
> in a previous release, we tend to classify them as not-blocking
> by default, based on the idea that normally, severe issues tend
> to be discovered quickly, so even if we had missed it for the .0,
> we would have known about it for the .1. Also, if the bug was
> in a release already, doing another release with that bug shouldn't
> hurt (that is, would not make things worse). However, just as before,
> this is only a guideline, and we can review each bug on a case by
> case basis, and with sufficient merit, long-time bugs can still be
> classified as blocking.
>
> I should also add that blocking/non-blocking is just a decision
> process meant to guide the release process. Non-blocking does not
> mean that the next release will necessarily have the bug as well.
> It just indicates that we are not expecting to be waiting for
> those issues to be resolved before we release. Contributing a patch
> ahead of the release process would ensure that the issue gets fixed
> in the release.

Great! thanks for taking the time to clarify that for me :)

Re: One month away from GDB 8.0 branching

[Antoine Tremblay]

Yao Qi writes:

> On Thu, Feb 16, 2017 at 12:23 AM, Antoine Tremblay
> <antoine.tremblay@ericsson.com> wrote:
>>
>> I created a PR for this issue :
>> https://sourceware.org/bugzilla/show_bug.cgi?id=21169
>>
>> I've marked it Target Milestone 8.0
>>
>
> I prefer to fixing this issue in 8.0 too, but to be clear, this is a
> 7.11 -> 7.12 regression.
> We changed GDBserver to single step over breakpoint on July 2016, but 7.12 was
> released on Oct 2016.

Note however that the tests started failing when range-stepping got
enabled, the change in July is the main issue but the range stepping
introduced after 7.12 definetively made it worse to the point that the
tests failed...

So I would say it's a regression that got worse post 7.12...? Not sure
how to classify that?

Re: One month away from GDB 8.0 branching

[Joel Brobecker]

> Note however that the tests started failing when range-stepping got
> enabled, the change in July is the main issue but the range stepping
> introduced after 7.12 definetively made it worse to the point that the
> tests failed...
> 
> So I would say it's a regression that got worse post 7.12...? Not sure
> how to classify that?

I would say that it depends on how often someone is likely to
hit the issue, and what the possible workarounds are.

More importantly, though, is anyone working on this issue as
we speak? For every blocking issue, there should be an assignee
who's taking charge of getting the issue fixed. Otherwise, we cannot
get updates on the issue, nor be sure that it'll get fixed in
a reasonable amount of time.

-- 
Joel

Re: One month away from GDB 8.0 branching

[Antoine Tremblay]

Joel Brobecker writes:

>> Note however that the tests started failing when range-stepping got
>> enabled, the change in July is the main issue but the range stepping
>> introduced after 7.12 definetively made it worse to the point that the
>> tests failed...
>>
>> So I would say it's a regression that got worse post 7.12...? Not sure
>> how to classify that?
>
> I would say that it depends on how often someone is likely to
> hit the issue, and what the possible workarounds are.

Yes in light of your email about the blocking/non-blocking I'll discuss
that with Yao and Pedro. For my part and the users I know use this, it is
a likely issue... and there's no real workaround but to have a patched
GDB.

>
> More importantly, though, is anyone working on this issue as
> we speak? For every blocking issue, there should be an assignee
> who's taking charge of getting the issue fixed. Otherwise, we cannot
> get updates on the issue, nor be sure that it'll get fixed in
> a reasonable amount of time.

Yes that one is a bit tricky, I'm on leave until April but it all
depends on what the way forward is and the complexity of the fix...

It's being discussed at least we'll see who can come up with the code
hopefully for 8.0.

Thanks!,
Antoine