Not everyone wants to work and collaborate the way you do. It seems absurd to me to force everyone to hold off on merging into a single branch just because a lot of us want to prioritize testing 4.0.
I think most committers are going to want to contribute to the 4.0 testing process more than they want to commit new features to trunk, but I also think people shouldn't be banned from new bringing in new features if that's what they want to do. You're essentially giving a blanket -1 to all new features for a 3-6 month period. On Mon, Jul 9, 2018 at 10:44 AM sankalp kohli <kohlisank...@gmail.com> wrote: > > How is this preventing someone from working and collaborating on an Apache > Project? You can still collaborate on making 4.0 more stable. > > Why will these committers not work on making 4.0 more stable and fix broken > tests? Considering we cannot release without test passing, how will these > features be used? > > On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad <j...@jonhaddad.com> wrote: > > > I don't see how changing the process and banning feature commits is > > going to be any help to the project. There may be a couple committers > > who are interested in committing new features. > > > > I'm a -1 on changing the branching strategy in a way that prevents > > people from working and collaborating on an Apache project. > > > > On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli <kohlisank...@gmail.com> > > wrote: > > > > > > I did not see a -1 but all +0s and a few +1s. > > > > > > On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie <jmcken...@apache.org> > > wrote: > > > > > > > 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 > > > > > > > > > > > > -- > > Jon Haddad > > http://www.rustyrazorblade.com > > twitter: rustyrazorblade > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
