Re: Policy for grafting bug fixes from dev to stable

[Rik]

On 02/26/2019 02:32 PM, John W. Eaton wrote:
> 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.
>
In the end I found only 3 changesets that I thought need to be grafted so I
did that.

--Rik