I would like to back port as little as possible. I suggest the following criteria:
* By default, regressions are back ported to existing release branches. A bug is considered a regression if the functionality is present in the previous minor or patch version and is not affected by the bug there. * Critical and blocker issues, e.g., a CVE, can be back ported. * Other bugs and significant improvements, e.g., performance, may be back ported, the release manager should ideally be the one who decides on this. On Thu, Jul 12, 2018 at 12:25 AM, Vinod Kone <vinodk...@apache.org> wrote: > Ben, thanks for the clarification. I'm in agreement with the points you > made. > > Once we have consensus, would you mind updating the doc? > > On Wed, Jul 11, 2018 at 5:15 PM Benjamin Mahler <bmah...@apache.org> > wrote: > > > I realized recently that we aren't all on the same page with backporting. > > We currently only document the following: > > > > "Typically the fix for an issue that is affecting supported releases > lands > > on the master branch and is then backported to the release branch(es). In > > rare cases, the fix might directly go into a release branch without > landing > > on master (e.g., fix / issue is not applicable to master)." [1] > > > > This leaves room for interpretation about what lies outside of "typical". > > Here's the simplest way I can explain what I stick to, and I'd like to > hear > > what others have in mind: > > > > * By default, bug fixes at any level should be backported to existing > > release branches if it affects those releases. Especially important: > > crashes, bugs in non-experimental features. > > > > * Exceptional cases that can omit backporting: difficult to backport > fixes > > (especially if the bugs are deemed of low priority), bugs in experimental > > features. > > > > * Exceptional non-bug cases that can be backported: performance > > improvements. > > > > I realize that there is a ton of subtlety here (even in terms of which > > things are defined as bugs). But I hope we can lay down a policy that > gives > > everyone the right mindset for common cases and then discuss corner cases > > on-demand in the future. > > > > [1] http://mesos.apache.org/documentation/latest/versioning/ > > >
