On Thu, Feb 11, 2016 at 9:03 AM, Nick Dimiduk <[email protected]> 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? Andrew's monthly sweep is the way to do it best IMO. When done, there is a singular rather than a fractured focus and he's making the call what makes it in and what doesn't. Takes time though. St.Ack > By policy, that's anything > that's not a new feature. I'll veto anything that doesn't hold the > compatibility guidelines. The other PMC know the guidelines as well, so if > you're unsure you don't even have to wait on me -- ask any of them. You can > even guess whether I'm going to veto it through a quick review of our > guidelines [0] and by running your patch through the compatibility checker > [1]. It only takes a few extra minutes and it will ensure a reasonable > shelf-life for our release lines. > > Thanks a lot for all your effort, > Nick > > [0]: http://hbase.apache.org/book.html#hbase.versioning.post10 > [1]: > > https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=blob;f=dev-support/check_compatibility.sh;h=95dba003a60236e9911af9730654ded6977fe800;hb=refs/heads/master >
