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