> > 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 <[email protected]> wrote: > On Wed, Feb 27, 2019 at 3:33 PM Adar Lieber-Dembo > <[email protected]> > 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 >
