My proposal is that we implement everything you're suggesting, except we branch off as we have in the past rather than locking down trunk. I'd encourage everyone to work to improve 4.0 in some way or another, whether it be fixing bugs, testing in a staging environment (feedback), writing tooling (data loaders, stress testing, cluster deployment tools), improving unit / dtests tests and writing docs. But outright blocking folks from committing a feature they may have been working on for months makes me very uncomfortable. I don't think there's going to be much of this, but it seems a little authoritarian to me to mandate that it's not allowed.
My personal preference is that everyone commit to making 4.0 stable on day 1, and we work towards that goal as a community, but not in a manner that's so heavy handed. On Mon, Jul 9, 2018 at 11:06 AM sankalp kohli <kohlisank...@gmail.com> wrote: > > If some committers want to bring in features without a path forward for > releasing(as tests are broken), is that an acceptable state for you? How do > we get out of this state. > > Like I said in my original email, this is a "proposal" and I am trying to > see how we can improve things here. So if you are -1 on this, please help > us propose something else to get these tests pass? > > And thanks for giving your feedback. > > On Mon, Jul 9, 2018 at 10:50 AM Jonathan Haddad <j...@jonhaddad.com> wrote: > > > 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 > > > > -- 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
