On Sun, Nov 11, 2018 at 8:18 PM Misty Linville <mi...@apache.org> wrote:
> .... It's not great to guess about things like this. > We're making a big assumption that our users actually pay attention to > user@ > or more often dev@ in order to complain about a branch being retired too > quickly in time for us to listen. > > True. A phone home would be sweet so we had a bit of data on what versions and where. I was thinking of pushing the 2.0.3 and then just waiting until an ugly bug or someone spoke up before doing a 2.0.4... slo-mo death. On general topic, yeah, we should try to be time-based once over the stability humps (IMO branch-2.1 is candidate now for time-based releases). Lets try and get branch-2.2 stabilized so can push out a 2.2.0. Thanks, S > On Sun, Nov 11, 2018, 8:04 PM Stack <st...@duboce.net wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
