Sure...thats an addition to the 3 states I was thinking(-1,+/-0 and +1) :) On Mon, Jul 9, 2018 at 12:49 PM Josh McKenzie <jmcken...@apache.org> wrote:
> > > > 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 >
