I would also quibble about this: > The number of patches that we backport makes the "stable" branches less stable.
At least in our production settings, later versions of 0.98 are more stable and perform better than earlier ones as a rule. My experience refutes the above claim, but YMMV On Thu, Feb 11, 2016 at 11:00 AM, Andrew Purtell <apurt...@apache.org> wrote: > The criteria we use for branches >= 1.0 I think addresses this concern. > Remember: For 0.98, each 0.98.x is a new _minor_ release. For each 1.1.x > each new release is a _patch_ release. So it's likely that features make it > in to 0.98, because - new minors; but unlikely features make it into 1.1.x, > because - only a patch release. > > On Thu, Feb 11, 2016 at 10:33 AM, Elliott Clark <ecl...@apache.org> wrote: > >> I disagree. We should encourage people to keep up with releases otherwise >> things will become un-tenable. >> I would vote that we should push back critical and blocker bug fixes to >> 1.1 >> but small fixes should go in the active 1.X branch. The number of patches >> that we backport makes the "stable" branches less stable. >> >> On Thu, Feb 11, 2016 at 9:13 AM, Andrew Purtell <andrew.purt...@gmail.com >> > >> wrote: >> >> > Thanks Nick. Since you've asked I'll give 1.1 the same treatment. About >> > once or twice a month I sweep branch-1 for changes suitable for picking >> > back further. You have asked for patches for branch-1.1 to be posted to >> > respective issues. I can stop with that or do the same with 1.1 that >> I've >> > done with 0.98: if the patch applies cleanly or with minor fixup, >> relevant >> > sampled subset of unit tests pass, and the API compat checker says ok, >> then >> > I apply and push it directly. >> > >> > > On Feb 11, 2016, at 9:03 AM, Nick Dimiduk <ndimi...@apache.org> >> wrote: >> > > >> > > Heya folks, >> > > >> > > I'm sorry to say branch-1.1 is falling behind in terms of backporting >> > fixes >> > > and performance improvements. Anything that's not a new feature and >> that >> > > doesn't break our compatibility guidelines is explicitly acceptable >> and >> > > *should* be backported to the active release branches, 0.98 and >> > branch-1.1. >> > > Mr. Purtell does a lot of good work to keep up 0.98; I'm afraid I >> don't >> > > have the bandwidth to pursue the commit logs so diligently. >> > > >> > > Let's change our relationship slightly, dev community. If you're >> working >> > on >> > > a fix, please also post a patch for branch-1.1. 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 >> > >> > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
