From dev-return-50664-archive-asf-public=cust-asf.ponee.io@mesos.apache.org Mon Jul 16 20:28:34 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id F36DA180657 for ; Mon, 16 Jul 2018 20:28:33 +0200 (CEST) Received: (qmail 10049 invoked by uid 500); 16 Jul 2018 18:28:32 -0000 Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mesos.apache.org Delivered-To: mailing list dev@mesos.apache.org Received: (qmail 10025 invoked by uid 99); 16 Jul 2018 18:28:32 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jul 2018 18:28:32 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id AA3011801C3 for ; Mon, 16 Jul 2018 18:28:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.888 X-Spam-Level: * X-Spam-Status: No, score=1.888 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id i0lEBNc-BJ1I for ; Mon, 16 Jul 2018 18:28:28 +0000 (UTC) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 3441A5F39F for ; Mon, 16 Jul 2018 18:28:28 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id t2-v6so16077537edr.5 for ; Mon, 16 Jul 2018 11:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a0y/UZE7YJBWYOfVC+GMcOWBBKXqZM8VlhBc2SbEocA=; b=Z1UJob3T7ch/XNAskEYMrw4DwUQVc79NBVpGROHYdzS6tSsIB8Jk2AQH1Nj/l+cfDE BPyKCAmcJjNuQlBAHaC6la+LVDPai+iDKRRl35Xb8MMtBGMgeIOkAxsr2C1G2zYvCATv V3yv7zgYOocBv6BEXR2cql8ULiGi1qnjsIIt1sLHG5NWFGPUhduO5YexxdIaZ/dTndNs Alle1o1Du6mi9wXcThN1W3SfXPmVoJRTKoqIPFzDNa5mlyk9nMRZgZTDQKI+vv3vH0p5 AH02weP9fZOZn7fEEGb2yn80cofmRU8dwPNh4fqWbSpFi66yVanVuFmzKj5Jw8wUS/K7 HhFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a0y/UZE7YJBWYOfVC+GMcOWBBKXqZM8VlhBc2SbEocA=; b=U1JdyiybGS8Jr46N3rAnOQ+4m2NvlgGva2oq3EAnVKuQPM1EfnrDgk5V5k1fBsdIkc DuPKfiAOFGjKHXOJvCO0VWVHTToWNVrHuBHz7/BnQPSWejoxtrySZ1X8Husa68ANLRt/ V/oFPYsk0GhBFLMFZp7wise8KIsknEH1eCWd5g7Shc0OLkCRH2j72LmT/vNE0XExvW4k gFfe8mQRkcTW5Gg7d2/zEMrh/Mp5QktmzOkhuDeyGF+ZAcuBnzBDkT1YXtKpQLjeCOb2 nr6b6NawZliMbYcQ07kK05LAuvhLNuqMAWuq6+D1hid9890nyJXb8ZBwNClXcjBGB2oe 0YbQ== X-Gm-Message-State: AOUpUlFeQMpnRCdSzXLiy/hzcCPYglOkQYn8EwYh4O4LdsgnB6p9IpeI YylCbWBOtHMU12PD69g6I7ugJntF X-Google-Smtp-Source: AAOMgpeld1OvfjNvZXYs59eYSHVKoh0oPJTCbHhxYDPfd1sKdJaKvB1ZIe+idmomPXkei/FJB6OKsA== X-Received: by 2002:aa7:d4da:: with SMTP id t26-v6mr18630920edr.121.1531765707667; Mon, 16 Jul 2018 11:28:27 -0700 (PDT) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com. [209.85.208.47]) by smtp.gmail.com with ESMTPSA id c17-v6sm14699028edj.27.2018.07.16.11.28.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jul 2018 11:28:27 -0700 (PDT) Received: by mail-ed1-f47.google.com with SMTP id h1-v6so2022631eds.1 for ; Mon, 16 Jul 2018 11:28:26 -0700 (PDT) X-Received: by 2002:a50:ca4b:: with SMTP id e11-v6mr18452427edi.131.1531765706572; Mon, 16 Jul 2018 11:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:8930:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 11:28:25 -0700 (PDT) In-Reply-To: References: <40ee5afa9cffd8365cb5ff74f61e7c7f@posteo.net> From: Jie Yu Date: Mon, 16 Jul 2018 11:28:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Backport Policy To: user Cc: dev Content-Type: multipart/alternative; boundary="000000000000d1d9d6057121fefd" --000000000000d1d9d6057121fefd Content-Type: text/plain; charset="UTF-8" Greg, I like your idea of adding a prescriptive "policy" when evaluating whether a bug fix should be backported, and leave the decision to committer (because they have the most context, and avoid a bottleneck in the process). - Jie On Mon, Jul 16, 2018 at 11:24 AM, Greg Mann wrote: > My impression is that we have two opposing schools of thought here: > > 1. Backport as little as possible, to avoid unforeseen consequences > 2. Backport as much as proves practical, to eliminate bugs in > supported versions > > Do other people agree with this assessment? > > If so, how can we find common ground? One possible solution would be to > leave the decision on backporting up to the committer, without specifying a > project-wide policy. This seems to be the status quo, and would lead to > some variation across committers regarding what types of fixes are > backported. We could also choose to delegate the decision to the release > manager; I favor leaving the decision with the committer, to eliminate the > burden on release managers. > > Here's a thought: rather than defining a prescriptive "policy" that we > expect committers to abide by, we could enumerate in the documentation the > competing concerns that we expect committers to consider when making > decisions on backports. The committing docs could read something like: > > "When bug fixes are committed to master, the committer should evaluate the > fix to determine whether or not it should be backported to supported > versions. This is left to the committer, but they are expected to weigh the > following concerns when making the decision: > > - Every backported change comes with a risk of unintended > consequences. The change should be carefully evaluated to ensure that such > side-effects are highly unlikely. > - As the complexity of applying a backport increases due to merge > conflicts, the likelihood of unintended consequences also increases. Bug > fixes which require extensive rebasing should only be backported when the > bug is critical enough to warrant the risk. > - Users of supported versions benefit greatly from the resolution of > bugs in point releases. Thus, whenever concerns #1 and #2 can be allayed > for a given bug fix, it should be backported." > > > Cheers, > Greg > > > On Mon, Jul 16, 2018 at 3:06 AM, Alex Rukletsov > wrote: > >> Back porting as little as possible is the ultimate goal for me. My >> reasons are closely aligned with what Andrew wrote above. >> >> If we agree on this strategy, the next question is how to enforce it. My >> intuition is that committers will lean towards back porting their patches >> in arguable cases, because humans tend to overestimate the importance of >> their personal work. Delegating the decision in such cases to a release >> manager in my opinion will help us enforce the strategy of minimal number >> backports. As a bonus, the release manager will have a much better >> understanding of what's going on with the release, keyword: "more >> ownership". >> >> On Sat, Jul 14, 2018 at 12:07 AM, Andrew Schwartzmeyer < >> andrew@schwartzmeyer.com> wrote: >> >>> I believe I fall somewhere between Alex and Ben. >>> >>> As for deciding what to backport or not, I lean toward Alex's view of >>> backporting as little as possible (and agree with his criteria). My >>> reasoning is that all changes can have unforeseen consequences, which I >>> believe is something to be actively avoided in already released versions. >>> The reason for backporting patches to fix regressions is the same as the >>> reason to avoid backporting as much as possible: keep behavior consistent >>> (and safe) within a release. With that as the goal of a branch in >>> maintenance mode, it makes sense to fix regressions, and make exceptions to >>> fix CVEs and other critical/blocking issues. >>> >>> As for who should decide what to backport, I lean toward Ben's view of >>> the burden being on the committer. I don't think we should add more work >>> for release managers, and I think the committer/shepherd obviously has the >>> most understanding of the context around changes proposed for backport. >>> >>> Here's an example of a recent bugfix which I backported: >>> https://reviews.apache.org/r/67587/ (for MESOS-3790) >>> >>> While normally I believe this change falls under "avoid due to >>> unforeseen consequences," I made an exception as the bug was old, circa >>> 2015, (indicating it had been an issue for others), and was causing >>> recurring failures in testing. The fix itself was very small, meaning it >>> was easier to evaluate for possible side effects, so I felt a little safer >>> in that regard. The effect of not having the fix was a fatal and undesired >>> crash, which furthermore left troublesome side effects on the system (you >>> couldn't bring the agent back up). And lastly, a dependent project (DC/OS) >>> wanted it in their next bump, which necessitated backporting to the release >>> they were pulling in. >>> >>> I think in general we should backport only as necessary, and leave it on >>> the committers to decide if backporting a particular change is necessary. >>> >>> >>> On 07/13/2018 12:54 am, Alex Rukletsov 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 >>>> 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 >>>>> 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 >>>>> 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 < >>>>> bmahler@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/ >>>>> > > > >>>>> > > >>>>> > >>>>> >>>>> >>> >> > --000000000000d1d9d6057121fefd--