Re: Testing 4.0 Post-Freeze

+1 from me as well. Let's try it out On 7/10/18, 11:23 AM, "Sam Tunnicliffe" wrote: +1 here too On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson wrote: > +1 here as well > > On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko > wrote: > > > +1 from me too

Re: Testing 4.0 Post-Freeze

If this motivates individuals and organizations to contribute time and resources to testing more before the release then +1. The varied testing before the release will make a huge difference. > On Jul 10, 2018, at 12:30 PM, Jeff Jirsa wrote: > > Ultimately, we have a consensus driven developm

Re: Testing 4.0 Post-Freeze

+1 here too On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson wrote: > +1 here as well > > On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko > wrote: > > > +1 from me too. > > > > — > > AY > > > > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote: > > > > > > > We have done all

Re: Testing 4.0 Post-Freeze

> On Jul 10, 2018, at 10:18 AM, Jonathan Haddad wrote: > > I guess I look at the initial voting in of committers as the process > by which people are trusted to merge things in. This proposed process > revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily > picked) wants to merge

Re: Testing 4.0 Post-Freeze

You're right - if we do decide we're wrong we can always create the branch later. I retract my -1. On Tue, Jul 10, 2018 at 10:50 AM Benedict Elliott Smith wrote: > > It’s not like this is an irrevocable change. > > If we encounter a scenario that seems to question its validity, or its > general

Re: Testing 4.0 Post-Freeze

+1 here as well On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko wrote: > +1 from me too. > > — > AY > > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote: > > > > We have done all this for previous releases and we know it has not > worked > > well. So how giving it one more

Re: Testing 4.0 Post-Freeze

It’s not like this is an irrevocable change. If we encounter a scenario that seems to question its validity, or its general applicability, it can be raised on the mailing list and we can revisit the decision, surely? I can think of at least one way to weaken the rules in such a scenario, wit

Re: Testing 4.0 Post-Freeze

I guess I look at the idea of changing the branching strategy as a means of blocking work as a very odd way of solving a human problem. Having a majority of votes temporarily block potentially good work might be a good thing, and it might not matter at all. It might also frustrate some folks who h

Re: Testing 4.0 Post-Freeze

That’s a peculiar way of looking at it. Committer status is not an absolute right to autonomy over the codebase. It’s an embodiment of trust that you will follow the community's prevailing rules around commit, and that you’re competent to do so. If the community wants to change those rules

Re: Testing 4.0 Post-Freeze

Ultimately, we have a consensus driven development. If Jonathan or Dave strongly disagrees with this, they can share their strong disagreement. Jonathan shared his concern about dissuading contributors. What's absurd is trying the same thing we've tried for 10 years and expecting things to magica

Re: Testing 4.0 Post-Freeze

I guess I look at the initial voting in of committers as the process by which people are trusted to merge things in. This proposed process revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily picked) wants to merge a new feature into trunk during the freeze, now they're not allowed?

Re: Testing 4.0 Post-Freeze

Well put Mick +1 On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko wrote: > +1 from me too. > > — > AY > > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote: > > > > We have done all this for previous releases and we know it has not > worked > > well. So how giving it one mo

Re: Testing 4.0 Post-Freeze

+1 from me too. — AY On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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

Re: Testing 4.0 Post-Freeze

+1. > On 9 Jul 2018, at 20:17, Mick Semb Wever 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? > > > I (a

Re: Testing 4.0 Post-Freeze

> 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? I (again) agree with you Sankalp :-) Why not try something new? It's easi

Re: Testing 4.0 Post-Freeze

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 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: Testing 4.0 Post-Freeze

> > 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 wrote: > What I’m saying is that for new contributors, not branching has a cost

Re: Testing 4.0 Post-Freeze

The most impactful change that I can see is the people that are involved with development who are willing to -1 a release. Those of us with votes are TLP have a big incentive for 4.0 to be stable - we want people to upgrade. I assume folks at Netflix, Apple are also very incentivized to see a ver

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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 whe

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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 b

Re: Testing 4.0 Post-Freeze

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 Ap

Re: Testing 4.0 Post-Freeze

I did not see a -1 but all +0s and a few +1s. On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 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

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

Does anyone has any more feedback on this? > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko 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 eit

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

Correct. On Wed., 4 Jul. 2018, 15:21 sankalp kohli, wrote: > Hi Kurt, >Thank you for your feedback. I am reading your comment as +1 on > the idea of working on making a solid release but +0 on branching model. Is > that correct? > Thanks, > Sankalp > > On Tue, Jul 3, 2018 at 10:09 PM

Re: Testing 4.0 Post-Freeze

Hi Kurt, Thank you for your feedback. I am reading your comment as +1 on the idea of working on making a solid release but +0 on branching model. Is that correct? Thanks, Sankalp On Tue, Jul 3, 2018 at 10:09 PM kurt greaves wrote: > > > > but by committing to reserving trunk for stabi

Re: Testing 4.0 Post-Freeze

> > but by committing to reserving trunk for stabilizing changes until the > beta, we focus our effort on polishing and delivering the release. No, committing to testing, bug fixing, and validating focuses our effort on polishing and delivering the release. Committing to reserving trunk for stabil

Re: Testing 4.0 Post-Freeze

Here’s why I really like this proposal: – It focuses our thought and effort on what it’ll take for each of us to become confident in running Apache Cassandra 4.0 for our most critical applications *prior* to cutting the dot-zero release. – It marks a commitment we can make to our user community:

Re: Testing 4.0 Post-Freeze

tl;dr: +1 for committing to testing + bugfixing after feature freeze, but I can't really see how changing the branching strategy is going to have any impact at all. I really don't think it's a big deal. People will work based on whatever priorities they've been assigned, regardless of what you do

Re: Testing 4.0 Post-Freeze

> > > 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. > +1, like really yes!! because it's a step towards a more stable-master project. If trunk is focused on stabi

Re: Testing 4.0 Post-Freeze

Yes? -- Jeff Jirsa > On Jul 3, 2018, at 2:29 PM, Jonathan Ellis wrote: > > Is that worth the risk of demotivating new contributors who might have > other priorities? > >> On Tue, Jul 3, 2018 at 4:22 PM, Jeff Jirsa wrote: >> >> I think there's value in the psychological commitment that if s

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

At Netflix, we use NDBench extensively to ensure there are no performance regressions introduced between major releases since all our micro services are very sensitive to any latency changes. I see a value in community organizing efforts around the production re

Re: Testing 4.0 Post-Freeze

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 o

Re: Testing 4.0 Post-Freeze

I think the call to action for the community here is to focus efforts on testing and bug fixes than spending time on reviewing features. That said, tlp-stress looks interesting. Dinesh On Tuesday, July 3, 2018, 1:03:54 PM PDT, Jonathan Haddad wrote: I agree with Josh. I don’t see how

Re: Testing 4.0 Post-Freeze

Is that worth the risk of demotivating new contributors who might have other priorities? On Tue, Jul 3, 2018 at 4:22 PM, Jeff Jirsa 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 > rel

Re: Testing 4.0 Post-Freeze

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 wrote: > I agree with Josh. I don’t see how changing the conv

Re: Testing 4.0 Post-Freeze

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 littl

Re: Testing 4.0 Post-Freeze

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