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
