> > I did not see a -1 but all +0s and a few +1s. It's more accurate to say you have quite a few -0's, some +0's, and a few +1's, probably some -0.5's if you're into that.
On Mon, Jul 9, 2018 at 2:53 PM Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote: > What I’m saying is that for new contributors, not branching has a cost and > I think there are other ways to organize efforts. > > One of the suggestions was for each organization to test their own use > cases in the stabilization process. I don’t think that’s been done very > effectively previously. Most organizations only do any sort of significant > testing when they’re about to put their clusters on the line - i.e. once a > version has several post GA point releases. That’s logical and no one > wants to be the first one to production. However, if people were to agree > to do some form of testing pre-release, then I think that would be a step > in the right direction. In the early days of the project I tried to do > this in a small way by testing the Hadoop support for every release (major > and minor) since it wasn’t on everyone’s radar but was important to me. > Then I would vote with a non-binding vote and described what was tested. > > > On Jul 9, 2018, at 1:30 PM, sankalp kohli <kohlisank...@gmail.com> > wrote: > > > > We have done all this for previous releases and we know it has not worked > > well. So how giving it one more try is going to help here. Can someone > > outline what will change for 4.0 which will make it more successful? > > > > Not branching is one idea but we should discuss what will change now than > > iterating what has already happened. > > > > On Mon, Jul 9, 2018 at 11:25 AM Jeremy Hanna <jeremy.hanna1...@gmail.com > > > > wrote: > > > >> I wholeheartedly agree with efforts to make releases more stable and the > >> more contributors that add tests or test within the context of their own > >> use cases, the better. +1 non-binding to the idea of better, more > complete > >> testing for releases. > >> > >> When it comes to how to do this, I think that’s where there is > >> disagreement. I personally don’t think that branching detracts from the > >> goal of stabilization. There are a couple of personas involved here: > >> > >> * Longtime contributors/committers: I think it’s sufficient to generally > >> ask that whatever time/effort they can contribute be towards > stabilizing, > >> testing, and especially testing their production scenarios to cover more > >> surface area when it comes to usage edge cases. That along with testing > >> longer running things in those scenarios for other types of edge cases. > >> > >> * New contributors: They likely won’t know about the strategy. They’re > >> just poking around and looking at lhf tickets or tickets that they need > >> done. Those are typically low risk but at the same time we don’t want > to > >> compromise stability by merging those in. Reviewing low risk stuff for > >> inclusion doesn’t take a ton of time and gives them a sense that they > can > >> be of help and empowers them. After they have that first experience, > then > >> a longer term contributor could share with them a blog post or tldr > thread > >> summary about the 4.0 stabilization efforts (would be nice to have one > to > >> point people too once we're done). We could also start creating lhf > >> tickets with stabilization and testing in mind. > >> > >> Unless we want to make a fundamental change to the project’s process > >> (making trunk stable at all times going forward), then I don’t think > >> there’s a reason why branching would detract from these efforts. In > other > >> words if we’re just trying to say that we want to focus on stabilization > >> for the alpha/beta/rc of 4.0, then I would prefer branching along with > >> clear messaging. > >> > >> Jeremy > >> > >>> On Jul 9, 2018, at 12:43 PM, 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 > >>>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rustyrazorblade.com&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=4uhQot00l-PuEymqD360tNN_Nhl7Uy9JH3ch4SiWc3I&s=cKnTet4KURi1yMqHlSk4FGIQJIP9jys3E8-6zfDjoNo&e= > >>>> twitter: rustyrazorblade > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org
