It seems to me that putting the burden of deciding on backports on the release manager would actually increase the amount of work required. Simply cutting the release on a particular date is pretty quick - however, examining tickets to determine whether or not a particular fix should be backported seems like more effort?
The backport policy strikes me as a community decision, rather than an individual decision. The community discusses (as we're doing now :) and settles on a policy, which individual committers then execute. Putting each release manager in charge of the backport policy for that particular release would lead to inconsistency across releases. I'm not sure that this is a terrible thing, but it's not a particularly good thing either. I would propose that we establish a single backport policy that we all do our best to execute, with an understanding that there will always be room for exceptions in some situations. I like the idea of backporting all bug fixes which apply relatively cleanly. In addition, very critical bug fixes are worth backporting even when extensive work is required to backport them. Alex, could you elaborate on why you would like to backport as little as possible? I would like to better understand your motivations there :) Cheers, Greg On Fri, Jul 13, 2018 at 2:40 PM, Jie Yu <yujie....@gmail.com> wrote: > 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/ >> > > > > >> > > > >> > > >> > >> > >
