Kudu backport policy

[Adar Lieber-Dembo <ad...@cloudera.com.INVALID>]

A recent Slack discussion revealed that we may not have consensus on
how our project handles backports to older branches. This e-mail is an
attempt to build that consensus; please weigh in if you have an
opinion.

Perhaps it's best to start from first principles: when release x.y is
the latest released version of Kudu, and release x.y+1 is under
development, for which of all x.a (where a<y+1) releases do we expect
to see maintenance releases? In theory, any PMC member can kick off a
release of any version they choose. In practice, we've only done
maintenance releases for a handful of minors, and never more than one
maintenance release. So I think there's rough consensus that when
x.y+1 is under development, we're only supporting possible maintenance
releases for x.y. Put more simply, we should prepare for possible
maintenance releases only for the latest release of Kudu.

Here's a strawman backport policy: only backport to branches where we
expect possible maintenance releases. Currently, 1.8.0 is the latest
minor release, so we should actively backport to branch-1.8.x until
1.9.0 is released, at which point branch-1.9.x becomes the backport
target and branch-1.8.x is, for all intents and purposes, dead.

What sorts of patches merit backporting? Off the top of my head:
- Fixes that keep CI working (e.g. pinning of unpinned Python
dependencies that break).
- Fixes to security vulnerabilities.
- Data loss fixes.
- Performance fixes, provided the impact:risk ratio is very high.

What do you think?

Re: Kudu backport policy

[Andrew Wong <aw...@apache.org>]

>
> only backport to branches where we expect possible maintenance releases.


+1 on this, and on defining a "default" maintenance branch window of one
minor release. If for some reason we did need to go further back, we could
piece together some fixes from the tips of the more recent .x branches.

What sorts of patches merit backporting?
>

I'm on the fence about how aggressively we should backport. On the one
hand, we would ideally maintain that each release meets a certain level of
quality. On the other, I empathize with Mike, particularly when such
changes sometimes merit some revision to backport.

Having seen the pain that various build issues can bring, though, I feel
more strongly about backporting CI fixes, so at the very least, we reduce
the overhead of cutting new releases on old branches. For other changes, I
say leave it up to whoever is volunteering to cut the release; given
maintenance releases are so uncommon, they probably have an idea of what
they want in the release.


On Tue, Mar 5, 2019 at 1:12 PM Mike Percy <mp...@apache.org> wrote:

> On Wed, Feb 27, 2019 at 3:33 PM Adar Lieber-Dembo
> <ad...@cloudera.com.invalid>
> wrote:
>
> > What sorts of patches merit backporting? Off the top of my head:
> > - Fixes that keep CI working (e.g. pinning of unpinned Python
> > dependencies that break).
> >
> +1, I am even in favor of skipping code review in this case if another
> committer is not available to review the change.
>
>
> > - Fixes to security vulnerabilities.
>
> - Data loss fixes.
>
> - Performance fixes, provided the impact:risk ratio is very high.
>
> +1, assuming we plan to run an x.y.z release.
>
> Put more simply, we should prepare for possible maintenance releases only
> > for the latest release of Kudu.
>
> +1 on assuming we will not do maintenance releases for more than the
> previously-released version.
>
> I agree with the basic criteria you've outlined as good candidates for a
> maintenance release.
> However in general I am not in favor of asking committers to backport
> particular types of patches routinely, because we rarely do maintenance
> releases.
>
> Mike
>

Re: Kudu backport policy

[Mike Percy <mp...@apache.org>]

On Wed, Feb 27, 2019 at 3:33 PM Adar Lieber-Dembo <ad...@cloudera.com.invalid>
wrote:

> What sorts of patches merit backporting? Off the top of my head:
> - Fixes that keep CI working (e.g. pinning of unpinned Python
> dependencies that break).
>
+1, I am even in favor of skipping code review in this case if another
committer is not available to review the change.


> - Fixes to security vulnerabilities.

- Data loss fixes.

- Performance fixes, provided the impact:risk ratio is very high.

+1, assuming we plan to run an x.y.z release.

Put more simply, we should prepare for possible maintenance releases only
> for the latest release of Kudu.

+1 on assuming we will not do maintenance releases for more than the
previously-released version.

I agree with the basic criteria you've outlined as good candidates for a
maintenance release.
However in general I am not in favor of asking committers to backport
particular types of patches routinely, because we rarely do maintenance
releases.

Mike

Re: Kudu backport policy

[Todd Lipcon <to...@cloudera.com.INVALID>]

Makes sense to me. At some point if we have some PMC member(s) volunteering
to do maintenance on older releases, we shouldn't prohibit it. But I think
setting a general expectation that we only do maintenance releases of the
latest minor is pretty reasonable, especially given we've been pretty good
about keeping our compatibility contracts clean.

-Todd

On Wed, Feb 27, 2019 at 3:33 PM Adar Lieber-Dembo <ad...@cloudera.com.invalid>
wrote:

> A recent Slack discussion revealed that we may not have consensus on
> how our project handles backports to older branches. This e-mail is an
> attempt to build that consensus; please weigh in if you have an
> opinion.
>
> Perhaps it's best to start from first principles: when release x.y is
> the latest released version of Kudu, and release x.y+1 is under
> development, for which of all x.a (where a<y+1) releases do we expect
> to see maintenance releases? In theory, any PMC member can kick off a
> release of any version they choose. In practice, we've only done
> maintenance releases for a handful of minors, and never more than one
> maintenance release. So I think there's rough consensus that when
> x.y+1 is under development, we're only supporting possible maintenance
> releases for x.y. Put more simply, we should prepare for possible
> maintenance releases only for the latest release of Kudu.
>
> Here's a strawman backport policy: only backport to branches where we
> expect possible maintenance releases. Currently, 1.8.0 is the latest
> minor release, so we should actively backport to branch-1.8.x until
> 1.9.0 is released, at which point branch-1.9.x becomes the backport
> target and branch-1.8.x is, for all intents and purposes, dead.
>
> What sorts of patches merit backporting? Off the top of my head:
> - Fixes that keep CI working (e.g. pinning of unpinned Python
> dependencies that break).
> - Fixes to security vulnerabilities.
> - Data loss fixes.
> - Performance fixes, provided the impact:risk ratio is very high.
>
> What do you think?
>


-- 
Todd Lipcon
Software Engineer, Cloudera