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 <anto...@apache.org>: > >>"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) > > >
