I'd also encourage RMs to make occasional (I try monthly) sweeps of upstream branch history to get a lay of the land and identify changes you think should be in your RC but didn't get there by commit - and pick those back if so. Allow an extra few days when scheduling time to work on that next RC.
> On Feb 11, 2016, at 1:13 PM, Andrew Purtell <andrew.purt...@gmail.com> wrote: > > The majority of changes in branch-1 that I see are bug fixes. Only committer > attention and bandwidth prevents application to all places. A few are new > features or bug fixes that break APIs or change behavior in a manner > unsuitable for a patch release. Spotting those isn't hard. Finally, it's true > as change application rate increases so does entropy, so occasional test > failures or reverts due to issues found during a RC are inevitable. I don't > think any rules or process can be superior to committer case by case best > judgement. Likewise, PMC attention to the changes incorporated in a release > candidate. > >> On Feb 11, 2016, at 12:42 PM, Josh Elser <josh.el...@gmail.com> wrote: >> >> Stack wrote: >>>> ... >>>>> Let's change our relationship slightly, dev community. If you're working >>>>> on >>>>> a fix, please also post a patch for branch-1.1. >>> >>> >>> It is a bit tough. That'd be a patch for four branches (at least), three of >>> which have diverged in key areas (master, branch-1 and branch-1.2, and >>> branch-1.1). Each patch takes a bit of time, especially if some fixup >>> needed, and then, if doing the application, there is watching the build >>> subsequently to see if my application broke the build (which a seemingly >>> innocuous application does with some regularity). A critical fix should be >>> done in all branches, but for less-than-critical, I'd be for encouraging >>> folks to (rolling) upgrade to get new performance/feature? >> >> It's a slippery slope trying to decide what has merits to get backported as >> well. After meeting compatibility guarantees, how do you decide if some >> change if critical enough to be considered for the non-EOL'ed 1.x branches? >> >> Given that there's only now a 1.2.0 release in the works, it's also kind of >> crappy to try to restrict what can go out on a 1.1. I'm all for release >> early/often, but that needs to be measured against the cycles to make those >> new major/minor releases (so that we can subsequently encourage the >> community to adopt those new releases).
