Yes. Was suggesting retiring branch-2.0 and suggesting that we throw the troops against the branch-2.2 flank. Agree though that if there are folks who want more releases, lets do them (please speak up if this is so). 2.0.3 will be good since it close to 2.1.1. Unless demand, 2.0.4 will likely drag.
In my limited testing (10B ITBLL), branch-2.1 (2.1.1) was making a good showing; better than what we've shipped previous in the past (in my estimation). Thanks Allan. (FYI branch-1.0 as short-lived if any consolation). S On Sun, Nov 11, 2018 at 6:12 PM Allan Yang <allan...@apache.org> wrote: > Stack, are you suggest about retiring branch-2.0? I think it is OK, since > branch-2.0 is almost the same with branch-2.1 now(except some new feature > on replication). Yes, agree that we should help out on branch-2.2. AMv2 > changed a lot in branch-2, there may still have some work to do to make > branch-2.2 stable. But at same time, I think we can mark branch-2.1 as > stable. We have done tremendous work on this branch, and recently ITBLLs > shows it is already stable enough(based on our internal version, but most > of patches in branch-2.1 was backported) > Best Regards > Allan Yang > > > Stack <st...@duboce.net> 于2018年11月12日周一 上午6:57写道： > > > Agree w/ Duo that the 2.x releases have been gated on stability > watersheds > > rather than features. > > > > What else do we need to add to HBCK2 Duo (apart from a release)? > > > > Related, I was going to work on a 2.0.3 release. It has been a while and > a > > bunch of good stability work has made it into branch-2.0. Thereafter > > though, I was going to let branch-2.0 go unless demand -- Allan Yang? -- > > and switch instead to helping out on branch-2.2. > > > > S > > > > On Thu, Nov 8, 2018 at 6:10 PM 张铎(Duo Zhang) <palomino...@gmail.com> > > wrote: > > > > > I think for the 2.x release the problem is that we are still busy on > > making > > > the code stable, or speak more clearly, to make the procedure v2 > > framework > > > stable... And another big problem is lacking of HBCK2 support. These > > things > > > are all big issues which prevent people to upgrade to 2.x. > > > > > > Once these things are done, I think a monthly release will not be a big > > > problem to the RMs. Just simply run an ITBLL(for now it is not easy to > > get > > > a successful run and then we need to find out why...), and then the > > > make_rc.sh can not everything for you... > > > > > > Sean Busbey <bus...@apache.org> 于2018年11月9日周五 上午9:45写道： > > > > > > > I think it just shifts the RM burden, no? Like instead of watching > e.g. > > > > branch-2.2 I instead need to watch branch-2. > > > > > > > > On Thu, Nov 8, 2018, 17:28 Josh Elser <els...@apache.org wrote: > > > > > > > > > I think what I'd be concerned about WRT time-based releases is the > > > > > burden on RM to keep the branch in a good state. Perhaps we need to > > not > > > > > push that onto an RM and do better about sharing that load (looking > > in > > > > > the mirror). > > > > > > > > > > However, I do like time-based releases as a means to avoid "hurt > > > > > feelings" (e.g. the personal ties of a developer to a feature. "The > > > > > release goes out on zzzz/yy/xx, this feature is not yet ready, can > go > > > > > out one month later.." etc) > > > > > > > > > > On 11/7/18 2:31 PM, Sean Busbey wrote: > > > > > > Hi folks! > > > > > > > > > > > > Some time ago we talked about trying to get back on track for a > > more > > > > > > regular cadence of minor releases rather than maintenance > releases > > > > > > (like how we did back pre-1.0). That never quite worked out for > the > > > > > > HBase 1.y line, but is still something we could make happen for > > HBase > > > > > > 2. > > > > > > > > > > > > We're coming up on 4 months since the 2.1 release line started. > ATM > > > > > > there are 63 issues in JIRA that claim to be in 2.2.0 and not in > > any > > > > > > 2.1.z version[1]. > > > > > > > > > > > > The main argument against starting to do a 2.2.0 release is that > > > > > > nothing springs out of that list as a "feature" that would entice > > > > > > users to upgrade. Waiting for these kinds of selling points to > > drive > > > a > > > > > > release is commonly referred to as "feature based releases." I > > think > > > > > > it would be fair to characterize the HBase 2.0 release as feature > > > > > > based centered on AMv2. > > > > > > > > > > > > An alternative to feature based releases is date based releases > > where > > > > > > we decide that e.g. we'll have a minor release each month > > regardless > > > > > > of how much is included in it. This is sometimes also called > "train > > > > > > releases" as an analogy to how trains leave a station on a set > > > > > > schedule without regard to which individual passengers are ready. > > > Just > > > > > > as you'd catch the next scheduled train if you miss-timed your > > > > > > arrival, fixes or features that aren't ready just go in the next > > > > > > regular release. > > > > > > > > > > > > Personally, I really like the idea of doing date based releases > for > > > > > > minor releases with maintenance releases essentially only > happening > > > on > > > > > > whatever our "stable" designator points at. It would mean those > who > > > > > > don't want the risk and benefits of our current release-ready > work > > > > > > could stay on a defined path while we could move away from > > > maintaining > > > > > > a ton of branches, some of which don't even see releases > (currently > > > ~3 > > > > > > that are > 3 months since a release). If some folks had a > specific > > > > > > need for a different minor release line and were willing to do > the > > > > > > backport and RM work for that line, they'd of course be free to > do > > > so. > > > > > > > > > > > > I know there are some current unknowns around 2.2 specifically. I > > > > > > think stack mentioned to me that there's an upgrade consideration > > > that > > > > > > we need to hammer out since I don't see anything specific to 2.2 > in > > > > > > the "Upgrade Paths" section of the ref guide right now. While I > am > > > > > > interested in getting 2.2 going specifically, I'd like to make > sure > > > we > > > > > > address the general topic of regularly getting new minor releases > > > out. > > > > > > If we already had an expectation that there'd be a minor release > > > every > > > > > > e.g. month or 2 months then I expect whatever upgrade issue would > > > have > > > > > > been addressed as a part of the change that caused it going in. > > > > > > > > > > > > What do folks think? > > > > > > > > > > > > [1]: > > > > > > https://s.apache.org/AAma > > > > > > > > > > > > > > > > > > > > >
