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)
