Re: GDB 8.2 branch 2018-06-22 Update

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Friday, June 22 2018, Joel Brobecker wrote:

>> 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.

Thanks for the throrough explanation, it's always good to understand
more about the whole process.

I agree with you: the patch is a bit risky, indeed.  Even though I'm
trying to extend the existing tests and make sure that it works as it
should, there's always the possibility of making a mistake, especially
if we rush things.

> 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.

You're absolutely right.  I've been thinking about that myself, and
that's why I decided to send the e-mail and ask more details about the
process of backporting.  Curiously, we at Red Hat have had to discuss a
very similar situation involving this same patch, and we also decided to
postpone including it in a next RHEL GDB release for the same reason.

Having said all that, I would like to request the removal of the IPv6
patch from the list of blocking features for the branch.  I think it's
better for Pedro as well, because this way he doesn't have to try to
review things like crazy before next weekend.

Thanks a lot,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/