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 > > > >
