hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: Backporting to active branches
Date Thu, 11 Feb 2016 21:13:08 GMT
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.elser@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).

Mime
View raw message