Sound like there is no need to clarify or amend what is already spelled out in
RFC[1]:
* Backports can be made to dormant support branches without requiring a
proposal or votes, subject to the "exercise good judgement" clause in the RFC.
* Backports to multiple support branches can be made in any order as long as
eventually all gaps are filled (make sure the Fix Versions list in Jira always
accurately reflects which branches do have the fix).
On 8/28/20, 1:10 PM, "Owen Nichols" <onich...@vmware.com> wrote:
I noticed a recent change on support/1.12 that was not preceded by a
backport proposal.
I re-read the Shipping Patch Releases RFC[1] which was adopted earlier this
year, and it doesn’t seem to mention anywhere that a backport proposal is
required for “dormant” support branches.
However, it does explicitly call out “if a fix is present in release N-2 it
should also be present in N-1 and N releases.” Normally the best way to
satisfy this is to backport to support/1.13 first (which definitely does[2]
require a backport proposal as we have an active release in progress).
Questions for the Geode community:
1. Is an out-of-order backport acceptable, and if so, should there be
any upper limit on how long to tolerate the inconsistency before a revert would
be required on the older branch? The risk here is that a 1.12.1 could ship
before a 1.13.1, causing a user upgrading from 1.12.1 to 1.13.0 to experience a
regression.
2. Should we clarify that ALL backports to support branches require a
dev list proposal and three +1’s? Or should we clarify that only backports to
an ACTIVE release branch need community approval?
[1] https://www.cwiki.us/display/GEODE/Shipping+patch+releases
[2]
https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode#ReleasingApacheGeode-Acceptcriticalfixestothesupportbranch
