mesos-user 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 Fri, 13 Jul 2018 21:40:36 GMT
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 <alex@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 <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
View raw message