What did we land on? Sounds like we're pretty split without consensus on "change the old branching strategy and reject new things on trunk during stabilization" vs. "keep doing things the way we did but message strongly that we won't be reviewing new things until 4.0 is stable".
On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli <kohlisank...@gmail.com> wrote: > Does anyone has any more feedback on this? > > > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko <alek...@apple.com> wrote: > > > > For what it’s worth, I’m fine with both formal branching-level freeze > and informal ‘let people commit to trunk if they can find a reviewer’ one > and will support either. > > > > So long as either/both are communicated to the contributors, the only > difference is in where new feature work gets accumulated: will stay a bit > longer in personal branches in the latter way. > > > > — > > AY > > > > On 4 July 2018 at 01:30:40, sankalp kohli (kohlisank...@gmail.com) > wrote: > > > > Having an explicit way to tell the community that we all will work on > > testing is better than writing a patch which will sit without review > for > > months. I think not having your patch reviewed for months is more > > discouraging than following the community and helping with stability of > > 4.0. > > > > > > > > On Tue, Jul 3, 2018 at 3:02 PM Josh McKenzie <jmcken...@apache.org> > wrote: > > > >>> > >>> We propose that between the September freeze date and beta, a new > branch > >>> would not be created and trunk would only have bug fixes and > performance > >>> improvements committed to it. > >> > >> > >> This is more of a call to action and announcement of intent than an > attempt > >>> to > >>> enforce policy; we can and probably will branch off 4.0, and keep > trunk > >>> technically active. > >> > >> These are two very different statements. :) Which is it? > >> > >> On Tue, Jul 3, 2018 at 5:57 PM Aleksey Yeshchenko <alek...@apple.com> > >> wrote: > >> > >>> If we want to have a stable, usable 4.0.0 release out in the next > 6-12 > >>> months, there needs to be a focused effort on getting it out - or > else > >>> it’ll just never happen. > >>> > >>> This is more of a call to action and announcement of intent than an > >>> attempt to enforce policy; we can and probably will branch off 4.0, > and > >>> keep trunk technically active. But so long as there is a critical mass > of > >>> active contributors who are on board with only/mostly working on > >> stability, > >>> bug fixes, and validation - both as assignees and reviewers - we’ll > have > >> a > >>> de-facto freeze. > >>> > >>> And I have a feeling that there is such a critical mass. > >>> > >>> — > >>> AY > >>> > >>> On 3 July 2018 at 22:23:38, Jeff Jirsa (jji...@gmail.com) wrote: > >>> > >>> I think there's value in the psychological commitment that if someone > has > >>> time to contribute, their contributions should be focused on > validating a > >>> release, not pushing future features. > >>> > >>> > >>> On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad <j...@jonhaddad.com> > >>> wrote: > >>> > >>>> I agree with Josh. I don’t see how changing the convention around > trunk > >>>> will improve the process, seems like it’ll only introduce a handful > of > >>>> rollback commits when people forget. > >>>> > >>>> Other than that, it all makes sense to me. > >>>> > >>>> I’ve been working on a workload centric stress tool on and off for a > >>> little > >>>> bit in an effort to create something that will help with wider > adoption > >>> in > >>>> stress testing. It differs from the stress we ship by including > fully > >>>> functional stress workloads as well as a validation process. The > idea > >>> being > >>>> to be flexible enough to test both performance and correctness in > LWT > >>> and > >>>> MVs as well as other arbitrary workloads. > >>>> > >>>> > >>> > >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_thelastpickle_tlp-2Dstress&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE&e= > > >>> > >>>> > >>>> Jon > >>>> > >>>> > >>>> On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie <jmcken...@apache.org> > > >>>> wrote: > >>>> > >>>>> Why not just branch a 4.0-rel and bugfix there and merge up while > >>> still > >>>>> accepting new features or improvements on trunk? > >>>>> > >>>>> I don't think the potential extra engagement in testing will > balance > >>> out > >>>>> the atrophy and discouraging contributions / community engagement > >>> we'd > >>>> get > >>>>> by deferring all improvements and new features in an open-ended > way. > >>>>> > >>>>> On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli <kohlisank...@gmail.com > > >>> > >>> > >>>>> wrote: > >>>>> > >>>>>> Hi cassandra-dev@, > >>>>>> > >>>>>> With the goal of making Cassandra's 4.0 the most stable major > >>> release > >>>> to > >>>>>> date, we would like all committers of the project to consider > >>> joining > >>>> us > >>>>> in > >>>>>> dedicating their time and attention to testing, running, and > fixing > >>>>> issues > >>>>>> in 4.0 between the September freeze and the 4.0 beta release. This > >>>> would > >>>>>> result in a freeze of new feature development on trunk or branches > >>>> during > >>>>>> this period, instead focusing on writing, improving, and running > >>> tests > >>>> or > >>>>>> fixing and reviewing bugs or performance regressions found in 4.0 > >>> or > >>>>>> earlier. > >>>>>> > >>>>>> How would this work? > >>>>>> > >>>>>> We propose that between the September freeze date and beta, a new > >>>> branch > >>>>>> would not be created and trunk would only have bug fixes and > >>>> performance > >>>>>> improvements committed to it. At the same time we do not want to > >>>>> discourage > >>>>>> community contributions. Not all contributors can be expected to > be > >>>> aware > >>>>>> of such a decision or may be new to the project. In cases where > new > >>>>>> features are contributed during this time, the contributor can be > >>>>> informed > >>>>>> of the current status of the release process, be encouraged to > >>>> contribute > >>>>>> to testing or bug fixing, and have their feature reviewed after > the > >>>> beta > >>>>> is > >>>>>> reached. > >>>>>> > >>>>>> > >>>>>> What happens when beta is reached? > >>>>>> > >>>>>> Ideally, contributors who have made significant contributions to > >>> the > >>>>>> release will stick around to continue testing between beta and > >>> final > >>>>>> release. Any additional folks who continue this focus would also > be > >>>>> greatly > >>>>>> appreciated. > >>>>>> > >>>>>> What about before the freeze? > >>>>>> > >>>>>> Testing new features is of course important. This isn't meant to > >>>>> discourage > >>>>>> development – only to enable us to focus on testing and hardening > >>> 4.0 > >>>> to > >>>>>> deliver Cassandra's most stable major release. We would like to > see > >>>>>> adoption of 4.0 happen much more quickly than its predecessor. > >>>>>> > >>>>>> Thanks for considering this proposal, > >>>>>> Sankalp Kohli > >>>>> > >>>> -- > >>>> Jon Haddad > >>>> > >>> > >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rustyrazorblade.com&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=paSngQpMm3DhoWay8lDuWEYELVOrti8evQeT1LodXdY&e= > > >>> > >>>> twitter: rustyrazorblade > >>>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org
