Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
> To rephrase myself - I think we shouldn't be taking stance that > MajorBranchX can't be released until features f1, f2, f2,...fN are all completed. Agree, we should not be blocked by any feature. Some new features don't conflict with current codes, I think we can just commit to branches and add a how-to-enable document into HBaseBook/ReleaseNote or enable it by default, when it is ready. For the issues that may break the branch to can-not-release state, I think we should never get them in and open a feature branch, merge them when they are all ready. Thanks, Phil 2017-03-10 9:41 GMT+08:00 Mikhail Antonov : > To rephrase myself - I think we shouldn't be taking stance that > MajorBranchX can't be released until features f1, f2, f2,...fN are all > completed. > > That's just not going to fly. There will always be features suddenly way > more complicated than they appeared, features that don't have enough > manpower behind them, features that are found to be less important then > they were thought to be. > > Instead we probably should say "branch-2 is being cut; (or, in kernel > parlance, here's merge window dates) whatever didn't make their way into it > will have a chance to go to branch-2.1, branch-2.2, branch-3". > > > > On Thu, Mar 9, 2017 at 5:29 PM, Mikhail Antonov > wrote: > > > >>"The only way forward for saving 2.0 at this point is to *make the > > branch > > and spin the RC." > > > > big +1 to that. > > > > I do also think that talking about planning in the context of open-source > > community development is a bit hard - there's no planning but what people > > do. If we release regularly, however, we would naturally be picking > > important things (features, fixes, optimizations), because things that > were > > planned but not completed up to some usable checkpoint state were, by the > > very definition, not truly important enough in the grand schema of > things. > > From the perspective, releasing regularly is more important than > preparing > > a list of must-have things and waiting to cross the last work item out > > before the release can be made. > > > > That does pose a problem of partially-completed features. Two viable ways > > to deal with them that I see are a) use feature branches more and b) > don't > > release off master (or, commit new code to some 'unstable' branch first, > > then pull to master). > > > > Thoughts? > > > > -Mikhail > > > > On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell > > wrote: > > > >> > For 2.0 release or future major release, what we need is planning - > >> THEME > >> > > >> (what is the biggest excitement for the release) and MUST-HAVE FEATURES. > >> > > >> All must-have features should have an owner and some estimate of > >> completing > >> > > >> time. > >> > >> With all due respect, this is just talk. Appeals to planning and "must > >> have" features has an import that decays proportionally to the time > since > >> the last time we had some words about it. 2.0 keeps slipping, slipping, > >> slipping. The PMC needs to come to terms with the actual amount of > >> development bandwidth we have available and set a cut point. Make it > >> happen, "do-ocracy" style. > >> > >> > >> > >> On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell > >> wrote: > >> > >> > Oh, I don't know. I may never be comfortable with a backport of MOB > into > >> > branch-1, but a branch-2 including it would be fine. > >> > > >> > And my point is not that making a branch-2 out of branch-1 is > desirable, > >> > simply that it could be the most practical way forward if we are stuck > >> on > >> > master with too much unfinished work that cannot be reverted in order > to > >> > make a production ready release. > >> > > >> > > >> > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang < > syuanjiang...@gmail.com> > >> > wrote: > >> > > >> >> I don't see a point to have branch-2 from branch-1. For > >> customer/users, > >> >> we > >> >> always can have a 1.x release to give them all the features they want > >> from > >> >> branch-1. > >> >> > >> >> My understand is that one of the difference of major release and > minor > >> >> release is that major release could break some backward > >> compatibility. If > >> >> any features that in master, but not in branch-1, as long as not > >> breaking > >> >> backward compatible, the owner of the feature always can back-port to > >> >> branch-1 if they desire. Today we don't have voting process to block > >> >> that. > >> >> > >> >> For 2.0 release or future major release, what we need is planning - > >> THEME > >> >> (what is the biggest excitement for the release) and MUST-HAVE > >> FEATURES. > >> >> All must-have features should have an owner and some estimate of > >> >> completing > >> >> time. Once the consensus is reached, then next step is execution - > the > >> >> release time would be based on progress of these must-have features. > >> >> > >> >> Thanks > >> >> Stephen > >> >> > >> >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
To rephrase myself - I think we shouldn't be taking stance that MajorBranchX can't be released until features f1, f2, f2,...fN are all completed. That's just not going to fly. There will always be features suddenly way more complicated than they appeared, features that don't have enough manpower behind them, features that are found to be less important then they were thought to be. Instead we probably should say "branch-2 is being cut; (or, in kernel parlance, here's merge window dates) whatever didn't make their way into it will have a chance to go to branch-2.1, branch-2.2, branch-3". On Thu, Mar 9, 2017 at 5:29 PM, Mikhail Antonov wrote: > >>"The only way forward for saving 2.0 at this point is to *make the > branch > and spin the RC." > > big +1 to that. > > I do also think that talking about planning in the context of open-source > community development is a bit hard - there's no planning but what people > do. If we release regularly, however, we would naturally be picking > important things (features, fixes, optimizations), because things that were > planned but not completed up to some usable checkpoint state were, by the > very definition, not truly important enough in the grand schema of things. > From the perspective, releasing regularly is more important than preparing > a list of must-have things and waiting to cross the last work item out > before the release can be made. > > That does pose a problem of partially-completed features. Two viable ways > to deal with them that I see are a) use feature branches more and b) don't > release off master (or, commit new code to some 'unstable' branch first, > then pull to master). > > Thoughts? > > -Mikhail > > On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell > wrote: > >> > For 2.0 release or future major release, what we need is planning - >> THEME >> > >> (what is the biggest excitement for the release) and MUST-HAVE FEATURES. >> > >> All must-have features should have an owner and some estimate of >> completing >> > >> time. >> >> With all due respect, this is just talk. Appeals to planning and "must >> have" features has an import that decays proportionally to the time since >> the last time we had some words about it. 2.0 keeps slipping, slipping, >> slipping. The PMC needs to come to terms with the actual amount of >> development bandwidth we have available and set a cut point. Make it >> happen, "do-ocracy" style. >> >> >> >> On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell >> wrote: >> >> > Oh, I don't know. I may never be comfortable with a backport of MOB into >> > branch-1, but a branch-2 including it would be fine. >> > >> > And my point is not that making a branch-2 out of branch-1 is desirable, >> > simply that it could be the most practical way forward if we are stuck >> on >> > master with too much unfinished work that cannot be reverted in order to >> > make a production ready release. >> > >> > >> > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang >> > wrote: >> > >> >> I don't see a point to have branch-2 from branch-1. For >> customer/users, >> >> we >> >> always can have a 1.x release to give them all the features they want >> from >> >> branch-1. >> >> >> >> My understand is that one of the difference of major release and minor >> >> release is that major release could break some backward >> compatibility. If >> >> any features that in master, but not in branch-1, as long as not >> breaking >> >> backward compatible, the owner of the feature always can back-port to >> >> branch-1 if they desire. Today we don't have voting process to block >> >> that. >> >> >> >> For 2.0 release or future major release, what we need is planning - >> THEME >> >> (what is the biggest excitement for the release) and MUST-HAVE >> FEATURES. >> >> All must-have features should have an owner and some estimate of >> >> completing >> >> time. Once the consensus is reached, then next step is execution - the >> >> release time would be based on progress of these must-have features. >> >> >> >> Thanks >> >> Stephen >> >> >> >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri >> >> wrote: >> >> >> >> > In my opinion, a major release is based on two simultaneous >> decisions: >> >> > >> >> > 1. Is it time; may be a year is a good time frame? (It's useless >> >> > accumulating too much code that is not battle tested and then expect >> >> people >> >> > to deploy it to production without experiencing a plethora of >> issues.) >> >> > >> >> > 2. Is there at least one "major feature" that is complete ? >> >> > >> >> > I think if we can answer yes to both these questions at any point in >> >> time, >> >> > it's a good idea to cut the RC and ask people to start testing it. >> >> > >> >> > the only way forward for saving 2.0 at this point is to *make the >> branch >> >> > and >> >> > > spin the RC >> >> > >> >> > +1 >> >> > >> >> > >> >> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell > > >> >> > wrote: >> >> > >> >> > > The only way forward for sav
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
Let's just cut branch-2 ASAP and set a deadline for the partially-completed features? 2017-03-10 9:29 GMT+08:00 Mikhail Antonov : > >>"The only way forward for saving 2.0 at this point is to *make the branch > and spin the RC." > > big +1 to that. > > I do also think that talking about planning in the context of open-source > community development is a bit hard - there's no planning but what people > do. If we release regularly, however, we would naturally be picking > important things (features, fixes, optimizations), because things that were > planned but not completed up to some usable checkpoint state were, by the > very definition, not truly important enough in the grand schema of things. > From the perspective, releasing regularly is more important than preparing > a list of must-have things and waiting to cross the last work item out > before the release can be made. > > That does pose a problem of partially-completed features. Two viable ways > to deal with them that I see are a) use feature branches more and b) don't > release off master (or, commit new code to some 'unstable' branch first, > then pull to master). > > Thoughts? > > -Mikhail > > On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell > wrote: > > > > For 2.0 release or future major release, what we need is planning - > THEME > > > > > (what is the biggest excitement for the release) and MUST-HAVE FEATURES. > > > > > All must-have features should have an owner and some estimate of > completing > > > > > time. > > > > With all due respect, this is just talk. Appeals to planning and "must > > have" features has an import that decays proportionally to the time since > > the last time we had some words about it. 2.0 keeps slipping, slipping, > > slipping. The PMC needs to come to terms with the actual amount of > > development bandwidth we have available and set a cut point. Make it > > happen, "do-ocracy" style. > > > > > > > > On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell > > wrote: > > > > > Oh, I don't know. I may never be comfortable with a backport of MOB > into > > > branch-1, but a branch-2 including it would be fine. > > > > > > And my point is not that making a branch-2 out of branch-1 is > desirable, > > > simply that it could be the most practical way forward if we are stuck > on > > > master with too much unfinished work that cannot be reverted in order > to > > > make a production ready release. > > > > > > > > > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang > > > > wrote: > > > > > >> I don't see a point to have branch-2 from branch-1. For > customer/users, > > >> we > > >> always can have a 1.x release to give them all the features they want > > from > > >> branch-1. > > >> > > >> My understand is that one of the difference of major release and minor > > >> release is that major release could break some backward compatibility. > > If > > >> any features that in master, but not in branch-1, as long as not > > breaking > > >> backward compatible, the owner of the feature always can back-port to > > >> branch-1 if they desire. Today we don't have voting process to block > > >> that. > > >> > > >> For 2.0 release or future major release, what we need is planning - > > THEME > > >> (what is the biggest excitement for the release) and MUST-HAVE > FEATURES. > > >> All must-have features should have an owner and some estimate of > > >> completing > > >> time. Once the consensus is reached, then next step is execution - > the > > >> release time would be based on progress of these must-have features. > > >> > > >> Thanks > > >> Stephen > > >> > > >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri > > >> wrote: > > >> > > >> > In my opinion, a major release is based on two simultaneous > decisions: > > >> > > > >> > 1. Is it time; may be a year is a good time frame? (It's useless > > >> > accumulating too much code that is not battle tested and then expect > > >> people > > >> > to deploy it to production without experiencing a plethora of > issues.) > > >> > > > >> > 2. Is there at least one "major feature" that is complete ? > > >> > > > >> > I think if we can answer yes to both these questions at any point in > > >> time, > > >> > it's a good idea to cut the RC and ask people to start testing it. > > >> > > > >> > the only way forward for saving 2.0 at this point is to *make the > > branch > > >> > and > > >> > > spin the RC > > >> > > > >> > +1 > > >> > > > >> > > > >> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell < > apurt...@apache.org> > > >> > wrote: > > >> > > > >> > > The only way forward for saving 2.0 at this point is to *make the > > >> branch > > >> > > and spin the RC. *Just do it. Kick out by revert what obviously > > isn't > > >> > > ready. Solicit help in getting partially finished things into > > working > > >> > > state. Kick them out too if the help does not arrive. > > >> > > > > >> > > Maybe too much is in a half done state and the scale of effort for > > >> those > > >> > > reverts is too hi
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
>>"The only way forward for saving 2.0 at this point is to *make the branch and spin the RC." big +1 to that. I do also think that talking about planning in the context of open-source community development is a bit hard - there's no planning but what people do. If we release regularly, however, we would naturally be picking important things (features, fixes, optimizations), because things that were planned but not completed up to some usable checkpoint state were, by the very definition, not truly important enough in the grand schema of things. >From the perspective, releasing regularly is more important than preparing a list of must-have things and waiting to cross the last work item out before the release can be made. That does pose a problem of partially-completed features. Two viable ways to deal with them that I see are a) use feature branches more and b) don't release off master (or, commit new code to some 'unstable' branch first, then pull to master). Thoughts? -Mikhail On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell wrote: > > For 2.0 release or future major release, what we need is planning - THEME > > > (what is the biggest excitement for the release) and MUST-HAVE FEATURES. > > > All must-have features should have an owner and some estimate of completing > > > time. > > With all due respect, this is just talk. Appeals to planning and "must > have" features has an import that decays proportionally to the time since > the last time we had some words about it. 2.0 keeps slipping, slipping, > slipping. The PMC needs to come to terms with the actual amount of > development bandwidth we have available and set a cut point. Make it > happen, "do-ocracy" style. > > > > On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell > wrote: > > > Oh, I don't know. I may never be comfortable with a backport of MOB into > > branch-1, but a branch-2 including it would be fine. > > > > And my point is not that making a branch-2 out of branch-1 is desirable, > > simply that it could be the most practical way forward if we are stuck on > > master with too much unfinished work that cannot be reverted in order to > > make a production ready release. > > > > > > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang > > wrote: > > > >> I don't see a point to have branch-2 from branch-1. For customer/users, > >> we > >> always can have a 1.x release to give them all the features they want > from > >> branch-1. > >> > >> My understand is that one of the difference of major release and minor > >> release is that major release could break some backward compatibility. > If > >> any features that in master, but not in branch-1, as long as not > breaking > >> backward compatible, the owner of the feature always can back-port to > >> branch-1 if they desire. Today we don't have voting process to block > >> that. > >> > >> For 2.0 release or future major release, what we need is planning - > THEME > >> (what is the biggest excitement for the release) and MUST-HAVE FEATURES. > >> All must-have features should have an owner and some estimate of > >> completing > >> time. Once the consensus is reached, then next step is execution - the > >> release time would be based on progress of these must-have features. > >> > >> Thanks > >> Stephen > >> > >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri > >> wrote: > >> > >> > In my opinion, a major release is based on two simultaneous decisions: > >> > > >> > 1. Is it time; may be a year is a good time frame? (It's useless > >> > accumulating too much code that is not battle tested and then expect > >> people > >> > to deploy it to production without experiencing a plethora of issues.) > >> > > >> > 2. Is there at least one "major feature" that is complete ? > >> > > >> > I think if we can answer yes to both these questions at any point in > >> time, > >> > it's a good idea to cut the RC and ask people to start testing it. > >> > > >> > the only way forward for saving 2.0 at this point is to *make the > branch > >> > and > >> > > spin the RC > >> > > >> > +1 > >> > > >> > > >> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell > >> > wrote: > >> > > >> > > The only way forward for saving 2.0 at this point is to *make the > >> branch > >> > > and spin the RC. *Just do it. Kick out by revert what obviously > isn't > >> > > ready. Solicit help in getting partially finished things into > working > >> > > state. Kick them out too if the help does not arrive. > >> > > > >> > > Maybe too much is in a half done state and the scale of effort for > >> those > >> > > reverts is too high. Fine. Renumber master as 3.0, and make a > branch-2 > >> > from > >> > > branch-1 and backport a select number of things from master into the > >> new > >> > > branch-2. Then release. I do a variation of this for the $dayjob so > >> would > >> > > be your man to turn to for driving this if that's the way forward. > >> > > > >> > > I know it's easy to recommend the labor of others. Depending on what > >> we > >>
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
> For 2.0 release or future major release, what we need is planning - THEME > (what is the biggest excitement for the release) and MUST-HAVE FEATURES. > All must-have features should have an owner and some estimate of completing > time. With all due respect, this is just talk. Appeals to planning and "must have" features has an import that decays proportionally to the time since the last time we had some words about it. 2.0 keeps slipping, slipping, slipping. The PMC needs to come to terms with the actual amount of development bandwidth we have available and set a cut point. Make it happen, "do-ocracy" style. On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell wrote: > Oh, I don't know. I may never be comfortable with a backport of MOB into > branch-1, but a branch-2 including it would be fine. > > And my point is not that making a branch-2 out of branch-1 is desirable, > simply that it could be the most practical way forward if we are stuck on > master with too much unfinished work that cannot be reverted in order to > make a production ready release. > > > On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang > wrote: > >> I don't see a point to have branch-2 from branch-1. For customer/users, >> we >> always can have a 1.x release to give them all the features they want from >> branch-1. >> >> My understand is that one of the difference of major release and minor >> release is that major release could break some backward compatibility. If >> any features that in master, but not in branch-1, as long as not breaking >> backward compatible, the owner of the feature always can back-port to >> branch-1 if they desire. Today we don't have voting process to block >> that. >> >> For 2.0 release or future major release, what we need is planning - THEME >> (what is the biggest excitement for the release) and MUST-HAVE FEATURES. >> All must-have features should have an owner and some estimate of >> completing >> time. Once the consensus is reached, then next step is execution - the >> release time would be based on progress of these must-have features. >> >> Thanks >> Stephen >> >> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri >> wrote: >> >> > In my opinion, a major release is based on two simultaneous decisions: >> > >> > 1. Is it time; may be a year is a good time frame? (It's useless >> > accumulating too much code that is not battle tested and then expect >> people >> > to deploy it to production without experiencing a plethora of issues.) >> > >> > 2. Is there at least one "major feature" that is complete ? >> > >> > I think if we can answer yes to both these questions at any point in >> time, >> > it's a good idea to cut the RC and ask people to start testing it. >> > >> > the only way forward for saving 2.0 at this point is to *make the branch >> > and >> > > spin the RC >> > >> > +1 >> > >> > >> > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell >> > wrote: >> > >> > > The only way forward for saving 2.0 at this point is to *make the >> branch >> > > and spin the RC. *Just do it. Kick out by revert what obviously isn't >> > > ready. Solicit help in getting partially finished things into working >> > > state. Kick them out too if the help does not arrive. >> > > >> > > Maybe too much is in a half done state and the scale of effort for >> those >> > > reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 >> > from >> > > branch-1 and backport a select number of things from master into the >> new >> > > branch-2. Then release. I do a variation of this for the $dayjob so >> would >> > > be your man to turn to for driving this if that's the way forward. >> > > >> > > I know it's easy to recommend the labor of others. Depending on what >> we >> > are >> > > going to do I can talk to work about freeing up time to help. >> > > >> > > >> > > On Thu, Mar 9, 2017 at 11:18 AM, Stack wrote: >> > > >> > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang >> > > wrote: >> > > > > >> > > > > >> > > > > So my suggestion is cutting branch-x faster and have some fixed >> > period, >> > > > for >> > > > > example, six month or one year? >> > > > > >> > > > >> > > > >> > > > You are right Phil. >> > > > >> > > > The Release Managers for the minor releases have been doing a good >> job >> > > > keeping up a decent release cadence but we have an abysmal track >> record >> > > > when it comes to pushing out majors. First we were afraid to commit >> -- >> > > > witness how long it took us to get to a 1.0 -- and then pushing out >> the >> > > 1.0 >> > > > took a monster effort. 2.0 looks to be a repeat of the errors of >> 1.0. >> > My >> > > > sense is that 2.0 is beyond saving at this stage. >> > > > >> > > > Can we do 3.0 different? As per your suggestion? >> > > > >> > > > St.Ack >> > > > >> > > >> > > >> > > >> > > -- >> > > Best regards, >> > > >> > >- Andy >> > > >> > > If you are given a choice, you believe you have acted freely. - >> Raymond >> > > Teller (via Peter Watts) >> > > >> > >> > >>
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
Oh, I don't know. I may never be comfortable with a backport of MOB into branch-1, but a branch-2 including it would be fine. And my point is not that making a branch-2 out of branch-1 is desirable, simply that it could be the most practical way forward if we are stuck on master with too much unfinished work that cannot be reverted in order to make a production ready release. On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang wrote: > I don't see a point to have branch-2 from branch-1. For customer/users, we > always can have a 1.x release to give them all the features they want from > branch-1. > > My understand is that one of the difference of major release and minor > release is that major release could break some backward compatibility. If > any features that in master, but not in branch-1, as long as not breaking > backward compatible, the owner of the feature always can back-port to > branch-1 if they desire. Today we don't have voting process to block that. > > For 2.0 release or future major release, what we need is planning - THEME > (what is the biggest excitement for the release) and MUST-HAVE FEATURES. > All must-have features should have an owner and some estimate of completing > time. Once the consensus is reached, then next step is execution - the > release time would be based on progress of these must-have features. > > Thanks > Stephen > > On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri > wrote: > > > In my opinion, a major release is based on two simultaneous decisions: > > > > 1. Is it time; may be a year is a good time frame? (It's useless > > accumulating too much code that is not battle tested and then expect > people > > to deploy it to production without experiencing a plethora of issues.) > > > > 2. Is there at least one "major feature" that is complete ? > > > > I think if we can answer yes to both these questions at any point in > time, > > it's a good idea to cut the RC and ask people to start testing it. > > > > the only way forward for saving 2.0 at this point is to *make the branch > > and > > > spin the RC > > > > +1 > > > > > > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell > > wrote: > > > > > The only way forward for saving 2.0 at this point is to *make the > branch > > > and spin the RC. *Just do it. Kick out by revert what obviously isn't > > > ready. Solicit help in getting partially finished things into working > > > state. Kick them out too if the help does not arrive. > > > > > > Maybe too much is in a half done state and the scale of effort for > those > > > reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 > > from > > > branch-1 and backport a select number of things from master into the > new > > > branch-2. Then release. I do a variation of this for the $dayjob so > would > > > be your man to turn to for driving this if that's the way forward. > > > > > > I know it's easy to recommend the labor of others. Depending on what we > > are > > > going to do I can talk to work about freeing up time to help. > > > > > > > > > On Thu, Mar 9, 2017 at 11:18 AM, Stack wrote: > > > > > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang > > > wrote: > > > > > > > > > > > > > > > So my suggestion is cutting branch-x faster and have some fixed > > period, > > > > for > > > > > example, six month or one year? > > > > > > > > > > > > > > > > > You are right Phil. > > > > > > > > The Release Managers for the minor releases have been doing a good > job > > > > keeping up a decent release cadence but we have an abysmal track > record > > > > when it comes to pushing out majors. First we were afraid to commit > -- > > > > witness how long it took us to get to a 1.0 -- and then pushing out > the > > > 1.0 > > > > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. > > My > > > > sense is that 2.0 is beyond saving at this stage. > > > > > > > > Can we do 3.0 different? As per your suggestion? > > > > > > > > St.Ack > > > > > > > > > > > > > > > > -- > > > Best regards, > > > > > >- Andy > > > > > > If you are given a choice, you believe you have acted freely. - Raymond > > > Teller (via Peter Watts) > > > > > > > > > > > -- > > Thanks and Regards, > > Ashu Pachauri > > > -- Best regards, - Andy If you are given a choice, you believe you have acted freely. - Raymond Teller (via Peter Watts)
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
I don't see a point to have branch-2 from branch-1. For customer/users, we always can have a 1.x release to give them all the features they want from branch-1. My understand is that one of the difference of major release and minor release is that major release could break some backward compatibility. If any features that in master, but not in branch-1, as long as not breaking backward compatible, the owner of the feature always can back-port to branch-1 if they desire. Today we don't have voting process to block that. For 2.0 release or future major release, what we need is planning - THEME (what is the biggest excitement for the release) and MUST-HAVE FEATURES. All must-have features should have an owner and some estimate of completing time. Once the consensus is reached, then next step is execution - the release time would be based on progress of these must-have features. Thanks Stephen On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri wrote: > In my opinion, a major release is based on two simultaneous decisions: > > 1. Is it time; may be a year is a good time frame? (It's useless > accumulating too much code that is not battle tested and then expect people > to deploy it to production without experiencing a plethora of issues.) > > 2. Is there at least one "major feature" that is complete ? > > I think if we can answer yes to both these questions at any point in time, > it's a good idea to cut the RC and ask people to start testing it. > > the only way forward for saving 2.0 at this point is to *make the branch > and > > spin the RC > > +1 > > > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell > wrote: > > > The only way forward for saving 2.0 at this point is to *make the branch > > and spin the RC. *Just do it. Kick out by revert what obviously isn't > > ready. Solicit help in getting partially finished things into working > > state. Kick them out too if the help does not arrive. > > > > Maybe too much is in a half done state and the scale of effort for those > > reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 > from > > branch-1 and backport a select number of things from master into the new > > branch-2. Then release. I do a variation of this for the $dayjob so would > > be your man to turn to for driving this if that's the way forward. > > > > I know it's easy to recommend the labor of others. Depending on what we > are > > going to do I can talk to work about freeing up time to help. > > > > > > On Thu, Mar 9, 2017 at 11:18 AM, Stack wrote: > > > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang > > wrote: > > > > > > > > > > > > So my suggestion is cutting branch-x faster and have some fixed > period, > > > for > > > > example, six month or one year? > > > > > > > > > > > > > You are right Phil. > > > > > > The Release Managers for the minor releases have been doing a good job > > > keeping up a decent release cadence but we have an abysmal track record > > > when it comes to pushing out majors. First we were afraid to commit -- > > > witness how long it took us to get to a 1.0 -- and then pushing out the > > 1.0 > > > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. > My > > > sense is that 2.0 is beyond saving at this stage. > > > > > > Can we do 3.0 different? As per your suggestion? > > > > > > St.Ack > > > > > > > > > > > -- > > Best regards, > > > >- Andy > > > > If you are given a choice, you believe you have acted freely. - Raymond > > Teller (via Peter Watts) > > > > > > -- > Thanks and Regards, > Ashu Pachauri >
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
In my opinion, a major release is based on two simultaneous decisions: 1. Is it time; may be a year is a good time frame? (It's useless accumulating too much code that is not battle tested and then expect people to deploy it to production without experiencing a plethora of issues.) 2. Is there at least one "major feature" that is complete ? I think if we can answer yes to both these questions at any point in time, it's a good idea to cut the RC and ask people to start testing it. the only way forward for saving 2.0 at this point is to *make the branch and > spin the RC +1 On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell wrote: > The only way forward for saving 2.0 at this point is to *make the branch > and spin the RC. *Just do it. Kick out by revert what obviously isn't > ready. Solicit help in getting partially finished things into working > state. Kick them out too if the help does not arrive. > > Maybe too much is in a half done state and the scale of effort for those > reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 from > branch-1 and backport a select number of things from master into the new > branch-2. Then release. I do a variation of this for the $dayjob so would > be your man to turn to for driving this if that's the way forward. > > I know it's easy to recommend the labor of others. Depending on what we are > going to do I can talk to work about freeing up time to help. > > > On Thu, Mar 9, 2017 at 11:18 AM, Stack wrote: > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang > wrote: > > > > > > > > > So my suggestion is cutting branch-x faster and have some fixed period, > > for > > > example, six month or one year? > > > > > > > > > You are right Phil. > > > > The Release Managers for the minor releases have been doing a good job > > keeping up a decent release cadence but we have an abysmal track record > > when it comes to pushing out majors. First we were afraid to commit -- > > witness how long it took us to get to a 1.0 -- and then pushing out the > 1.0 > > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. My > > sense is that 2.0 is beyond saving at this stage. > > > > Can we do 3.0 different? As per your suggestion? > > > > St.Ack > > > > > > -- > Best regards, > >- Andy > > If you are given a choice, you believe you have acted freely. - Raymond > Teller (via Peter Watts) > -- Thanks and Regards, Ashu Pachauri
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
The only way forward for saving 2.0 at this point is to *make the branch and spin the RC. *Just do it. Kick out by revert what obviously isn't ready. Solicit help in getting partially finished things into working state. Kick them out too if the help does not arrive. Maybe too much is in a half done state and the scale of effort for those reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 from branch-1 and backport a select number of things from master into the new branch-2. Then release. I do a variation of this for the $dayjob so would be your man to turn to for driving this if that's the way forward. I know it's easy to recommend the labor of others. Depending on what we are going to do I can talk to work about freeing up time to help. On Thu, Mar 9, 2017 at 11:18 AM, Stack wrote: > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang wrote: > > > > > > So my suggestion is cutting branch-x faster and have some fixed period, > for > > example, six month or one year? > > > > > You are right Phil. > > The Release Managers for the minor releases have been doing a good job > keeping up a decent release cadence but we have an abysmal track record > when it comes to pushing out majors. First we were afraid to commit -- > witness how long it took us to get to a 1.0 -- and then pushing out the 1.0 > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. My > sense is that 2.0 is beyond saving at this stage. > > Can we do 3.0 different? As per your suggestion? > > St.Ack > -- Best regards, - Andy If you are given a choice, you believe you have acted freely. - Raymond Teller (via Peter Watts)
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang wrote: > > > So my suggestion is cutting branch-x faster and have some fixed period, for > example, six month or one year? > You are right Phil. The Release Managers for the minor releases have been doing a good job keeping up a decent release cadence but we have an abysmal track record when it comes to pushing out majors. First we were afraid to commit -- witness how long it took us to get to a 1.0 -- and then pushing out the 1.0 took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. My sense is that 2.0 is beyond saving at this stage. Can we do 3.0 different? As per your suggestion? St.Ack
Re: A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
Yeah we have put too much things into the 2.0 release. And I believe there is a release schedule for 2.0 in the mailing-list? 2017-03-09 16:34 GMT+08:00 Phil Yang : > Nice article! Thanks for the authors. > > An off-the-topic suggestion to dev list: > > Now we commit some big and new features to master branch only, which will > be included in a new major version, for example, 2.0. However, a major > version is not upgraded very quickly, 1.0.0 was released two years ago and > we still don't release 2.0.0. HBASE-11425 is resolved more than one year > ago. In the worst case, if we make some work done and commit to master > branch just after cutting a new major release branch, the feature will be > released two years later or even longer. It is no need and no benefits to > wait so long. Bugs of the new feature in dev branches only are hardly to be > found, and committers may not be familiar with a feature which is committed > two years ago... > > So my suggestion is cutting branch-x faster and have some fixed period, for > example, six month or one year? > > Thanks, > Phil > > > 2017-03-09 14:24 GMT+08:00 Stack : > > > See writeup on how work done by your Yu Li, Sun Yu, Anoop Sam John, and > > Ramkrishna S Vasudevan improved throughput at scale on Singles Day 2016 @ > > Alibaba. > > > > Read all about it at https://blogs.apache.org/hbase/ > > > > Yours, > > St.Ack > > >
A suggestion for releasing major versions faster (Was: NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog)
Nice article! Thanks for the authors. An off-the-topic suggestion to dev list: Now we commit some big and new features to master branch only, which will be included in a new major version, for example, 2.0. However, a major version is not upgraded very quickly, 1.0.0 was released two years ago and we still don't release 2.0.0. HBASE-11425 is resolved more than one year ago. In the worst case, if we make some work done and commit to master branch just after cutting a new major release branch, the feature will be released two years later or even longer. It is no need and no benefits to wait so long. Bugs of the new feature in dev branches only are hardly to be found, and committers may not be familiar with a feature which is committed two years ago... So my suggestion is cutting branch-x faster and have some fixed period, for example, six month or one year? Thanks, Phil 2017-03-09 14:24 GMT+08:00 Stack : > See writeup on how work done by your Yu Li, Sun Yu, Anoop Sam John, and > Ramkrishna S Vasudevan improved throughput at scale on Singles Day 2016 @ > Alibaba. > > Read all about it at https://blogs.apache.org/hbase/ > > Yours, > St.Ack >
NOTICE: Nice testimony on benefits of the offheap read-path work now up on our blog
See writeup on how work done by your Yu Li, Sun Yu, Anoop Sam John, and Ramkrishna S Vasudevan improved throughput at scale on Singles Day 2016 @ Alibaba. Read all about it at https://blogs.apache.org/hbase/ Yours, St.Ack