mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jie Yu <yujie....@gmail.com>
Subject Re: Backport Policy
Date Mon, 16 Jul 2018 18:28:25 GMT
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 <greg@mesosphere.io> 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 <alex@mesosphere.com>
> 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 <bmahler@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 <alex@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 <vinodkone@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 <
>>>>> 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/
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message