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:16:54 GMT
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.purtell@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.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