+user, I probably it would be good to hear from users as well. Please see the original proposal as well as Alex's proposal and let us know your thoughts.
To continue the discussion from where Alex left off: > Other bugs and significant improvements, e.g., performance, may be back > ported, the release manager should ideally be the one who decides on this. I'm a little puzzled by this, why is the release manager involved? As we already document, backports occur when the bug is fixed, so this happens in the steady state of development, not at release time. The release manager only comes in at the time of the release itself, at which point all backports have already happened and the release manager handles the release process. Only blocker level issues can stop the release and while the release manager has a strong say, we should generally agree on what consists of a release blocking issue. Just to clarify my workflow, I generally backport every bug fix I commit that applies cleanly, right after I commit it to master (with the exceptions I listed below). On Thu, Jul 12, 2018 at 8:39 AM, Alex Rukletsov <a...@mesosphere.com> wrote: > 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/ > > > > > >
