> 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 <olorinb...@gmail.com>: > 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 <anto...@apache.org> > 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 <apurt...@apache.org> > > 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 <apurt...@apache.org> > >> 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 <ashu210...@gmail.com > > > >> >> 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 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 <st...@duboce.net> wrote: > >> >> > > > >> >> > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang < > >> yangzhe1...@apache.org> > >> >> > > 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) > >> > > >> > >> > >> > >> -- > >> Best regards, > >> > >> - Andy > >> > >> If you are given a choice, you believe you have acted freely. - Raymond > >> Teller (via Peter Watts) > >> > > > > > > > -- > Thanks, > Michael Antonov >
