I typically backport all bug fixes that cleanly apply and the risk is low. It's a judgement call, but many of the time, you can easily tell the risk is low.
I think my argument on why we want to do this is "why not". I want our software to have less bugs! Letting release manager decides which patch to backport or not does not scale. Some release managers might even become dormant after a while. - Jie On Fri, Jul 13, 2018 at 12:54 AM, Alex Rukletsov <a...@mesosphere.com> wrote: > This is exactly where our views differ, Ben : ) > > Ideally, I would like a release manager to have more ownership and less > manual work. In my imagination, a release manager has more power and > control about dates, features, backports and everything that is related to > "their" branch. I would also like us to back port as little as possible, to > simplify testing and releasing patch versions. > > On Fri, Jul 13, 2018 at 1:17 AM, Benjamin Mahler <bmah...@apache.org> > wrote: > > > +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/ > > > > > > > > > > > > > > >
