Re: GDB 8.2 branch 2018-06-22 Update

[Joel Brobecker <brobecker at adacore dot com>]

Hi Sergio,

> >   * (SergioDJ) Implement IPv6 support for GDB/gdbserver
> >
> >         From what I can tell, a v2 was sent, and a review done just
> >         a couple of days ago. Is that accurate?
> >
> >         [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00384.html
> >         [v1] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00238.html
> 
> Yes, that is accurate.  I'm now working on addressing a few aspects of
> the review, but it is still a bit unclear to me whether my new approach
> will be accepted or whether Pedro's suggested approach will work without
> problems.  I'm doing some testing to determine what to do next.

Thanks for the update.

> I'd like to know: if, for some reason, I'm unable to get this patch
> accepted until, say, next Thursday (June 28th), would it be OK to remove
> it from the list of blockers, and to backport it to the branch later?
> I'm asking because I don't want to be the one blocking the branching
> from happening, since the IPv6 feature is not a major regression/problem
> to be fixed anyway.

It depends on how intrusive the patch is, so it's a judgement call.
For patches that are really obviously safe, or for which we can say
that they cannot affect anything but themselves, the decision is
fairly easy. For other patches, we need to weigh the benefits vs
the risk we are taking.

One thing we could be doing is cut the branch, but then wait for
the branch to contain the changes we want before we create the first
pre-release. The pre-release tarballs are our last change for field
testing before we issue the first release, and in the case of a riskier
than usual patch, it can be one way to compromise.  We've only done it
once or twice, if memory serves, and the context was that there was
a difficult bug deemed critical that needed time to be fixed. Rather
than holding people's changes for master up while we spent time fixing
master, we just branched, knowing that we would have to backport the fix
before we could generate the first pre-release.

Who decides? I tend to defer to the maintainers who approved the patch
for master. But if, for some reason, the maintainer doesn't feel like
they can decide on their own, I am always happy to take a look and
provide my opinion on the matter -- it is just sometimes a bit more
difficult for me to make a fair assessment, not being entirely
familiar with the patch.

Scanning through v2 of your patch, my first reaction is that it seems
a bit risky to be backporting this to the branch, as it touches the
IPv4 layer quite a bit; it might be a lot of mechanical changes, but
what it shows is that it needs a careful analysis of the risk we are
taking. Having reviewed the patches in more details already, Pedro
might be better placed to let you know the changes of getting it in
after the branch.

You might also want to think about this another way: If you rush
your changes now and then we discover a major and difficult-to-fix bug,
it's less pressure to have to fix it on master, than it is to have
to do an emergency fix on the branch, possibly followed by an emergency
release... I say this not to discourage people, but to make sure that
the extra motivation of making a release doesn't turn into an unnecessary
constraint.

-- 
Joel