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