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