Re: [DISCUSS] Release cadence for HBase 2.y
Responses to several threads below, sorry in advance to folks that with mail readers this will mess up. On Wed, Nov 14, 2018 at 7:35 PM Andrew Purtell wrote: > > > 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, > > This is a bit premature to say never. I've been making steady releases of > 1.4 and am about to spin 1.5.0, a new branch branch-1.5. After 1.4.9 the > next release from 1.x will probably be 1.5.0. > > Point taken though, more frequent minors from 1.x, as discussed. > > (On the other hand the backports to 1.x have slowed significantly, as > actually we might hope with a focus on 2.0 and up going forward. So maybe a > minor after 1.5 won't be necessary. Time will tell.) > That's reenforcing my point though isn't it? We have done a good job of keeping up maintenance releases. In February it'll be 4 years since 1.0.0 and we're about to hit a fifth minor release. We've done nearly 40 maintenance releases. By comparison the 0.98 major version line lasted just shy of 3 years, had 24 minor releases, and just a handful of maintenance releases. We're 6 months into the HBase 2 release line. I'd like to start bending things closer to 0.98's pattern. On Sun, Nov 11, 2018 at 8:12 PM Allan Yang 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) The bit about "AMv2 changed in branch-2" is part of what worries me. I get that branch-2 releases haven't been as stable as branch-1 was, but I think the key to avoiding too much pain as folks who want to be on the newer side of things is to 1) minimize the incremental upgrade cost across minor releases and 2) minimize the number of branches we're trying to maintain as a project, because we don't have infinite dev bandwidth and test resources. Would it be so much worse for folks if there were a regular cadence of e.g. "new minor starts on the quarter. maintenance for it until the next minor"? They're still getting incrementally more stable releases. Part of my desire here is specifically to change how we think about i.e. "branch-2" so that folks don't take the liberty of backporting things before they are low-risk. Instead of having an RM punting things out of branch-2.y because their regular ITBLL got wonky they'd be punting things out of branch-2. We're a do-acracy, so as a reminder literally anyone could show up and be like "I'm personally going to handle maintenance releases for 2.7 because I don't want any more features" and at a minimum we'd work them through doing releases (probably making them a PMC in the process to maximize how much of the work they could do themselves). Probably they'd have to be willing to handle any non-trivial backports, or at least ping contributors to provide one. On Fri, Nov 9, 2018 at 9:57 AM Josh Elser wrote: > > Yes, agreed. My comment was more aimed at getting someone to "sign-up" > to do the work, regardless or what branch they're watching. > > I'd be in favor of trying it out, see how it works. What's the worst > that happens, we re-evaluate in three months? :shruggie: > Indeed. Let me try to get something written down about trying things out and see if folks are game. I'll find out soon if my expectations of the work burden for ongoing 1.2.z releases are realistic. If they are I might be willing/able to be the sign-ee.
Re: [DISCUSS] Release cadence for HBase 2.y
> 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, This is a bit premature to say never. I've been making steady releases of 1.4 and am about to spin 1.5.0, a new branch branch-1.5. After 1.4.9 the next release from 1.x will probably be 1.5.0. Point taken though, more frequent minors from 1.x, as discussed. (On the other hand the backports to 1.x have slowed significantly, as actually we might hope with a focus on 2.0 and up going forward. So maybe a minor after 1.5 won't be necessary. Time will tell.) On Wed, Nov 7, 2018 at 11:31 AM 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 > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [DISCUSS] Release cadence for HBase 2.y
I’ll start another thread about metrics gathering. On Tue, Nov 13, 2018 at 8:15 AM Stack wrote: > On Sun, Nov 11, 2018 at 8:18 PM Misty Linville 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 > > > > 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 > 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 于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 于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 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 /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 >
Re: [DISCUSS] Release cadence for HBase 2.y
On Sun, Nov 11, 2018 at 8:18 PM Misty Linville 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 > > 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 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 于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) > > > > 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 于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 > > > > > > > > > > > > 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 /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 > > > > > > > >
Re: [DISCUSS] Release cadence for HBase 2.y
This makes me wonder if we have, or have a way to get, analytics about the version people are running? 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. On Sun, Nov 11, 2018, 8:04 PM Stack 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 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 于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) > > > 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 于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 > > > > > > > > > > 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 /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
Re: [DISCUSS] Release cadence for HBase 2.y
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 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 于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) > > 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 于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 > > > > > > > > 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 /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 >
Re: [DISCUSS] Release cadence for HBase 2.y
But, since that some users may already have their production system on HBase-2.0.x, maybe we should consider their feelings, they are the 'first movers'. If we retire branch-2.0 so quickly, IIRC, the branch-2.0 will be the shortest life branch ever. I think it will hurt the feeling of those 'first movers'. If we take this into count, then I think maybe we should keep branch-2.0 at least one year. If the community is shorthanded, I volunteer to take responsible to decide/backport/release branch-2.0 since I was working on this branch most recently. Anyway, this thread is about releasing HBase2.2.x, I will vote a +1 for it, as for HBase-2.0.x, we can discuss later. Best Regards Allan Yang Allan Yang 于2018年11月12日周一 上午10:12写道： > 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 于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) >> 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 于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 > > > >> > > > 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 /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. >> > > > > >> > > > >
Re: [DISCUSS] Release cadence for HBase 2.y
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 于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) > 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 于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 > > > > > > 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 /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
Re: [DISCUSS] Release cadence for HBase 2.y
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) 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 于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 > > > > 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 /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 > > > > > > > > > >
Re: [DISCUSS] Release cadence for HBase 2.y
Yes, agreed. My comment was more aimed at getting someone to "sign-up" to do the work, regardless or what branch they're watching. I'd be in favor of trying it out, see how it works. What's the worst that happens, we re-evaluate in three months? :shruggie: On 11/8/18 8:45 PM, Sean Busbey wrote: 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 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 /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
Re: [DISCUSS] Release cadence for HBase 2.y
Oh, typo, 'the make_rc.sh can do everything for you' 张铎(Duo Zhang) 于2018年11月9日周五 上午10:09写道： > 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 于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 > >> > 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 /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 >> > > >> > >> >
Re: [DISCUSS] Release cadence for HBase 2.y
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 于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 > > 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 /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 > > > > > >
Re: [DISCUSS] Release cadence for HBase 2.y
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 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 /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 > > >
Re: [DISCUSS] Release cadence for HBase 2.y
This is an important topic. Thanks for bringing it up. For what it’s worth, I found the “release train” to work pretty well for patch releases from 1.1. That was only possible because of the stability of that branch. After the first couple releases, devs were pretty good about honoring the “bug fixes only” mandate. It was sometimes a challenge to summon a voting PMC quorum for each release. I also felt like I was sometimes stepping on the toes of other RM’s to attract said attention. I think a monthly cadance from multiple release branches would be too much burden of manual effort on our PMC. I’d like to see more automation for the bulk of the voting process, even giving our automation a binding vote. Thanks, Nick On Thu, 8 Nov 2018 at 15:28 Josh Elser 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 /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 > > >
Re: [DISCUSS] Release cadence for HBase 2.y
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 /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
[DISCUSS] Release cadence for HBase 2.y
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
