Re: Policy for grafting bug fixes from dev to stable

[John W. Eaton]

On 2/26/19 12:33 PM, Rik wrote:

> How do we want to handle bug fixes (not addition of new features) which
> were made on the development branch because the stable branch was in a code
> freeze during the release process?  Some of the patches fix legitimate
> bugs, but there was insufficient time for testing the patches so the code
> went to the dev branch.  One strategy is to assume that there are enough
> testers on the development branch so that by the time the 5.2.0 bug fix
> release is made in, say 4 months, there has been sufficient vetting of the
> patches.

It seems fine to graft fixes to stable.  I'd prefer to limit the fixes 
to important bug fixes.  Things like incorrect results or crashes should 
be fixed, but we should resist the urge to add new features.

As a separate issue, I made a number of small errors with this release 
so that it might be good to make a new release in maybe 2 months instead 
of 4.

> In that case, a suitably complex hg expression that extracts
> csets from the date when stable and dev diverged to the present, which were
> made on the development branch, and which reference "bug #" should produce
> an initial list for grafting back to stable.  The list would still need to
> be pared of bugs which were actually new feature additions.

Yes, that seems like a good way to generate a starting point.

jwe