Policy for grafting bug fixes from dev to stable

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Policy for grafting bug fixes from dev to stable

Rik-4
jwe,

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

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Policy for grafting bug fixes from dev to stable

John W. Eaton
Administrator
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



Reply | Threaded
Open this post in threaded view
|

Re: Policy for grafting bug fixes from dev to stable

Rik-4
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