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 (again) agree with you Sankalp :-) > > Why not try something new? > It's easier to discuss these things more genuinely after trying it out. > > One of the differences in the branching approaches: to feature-freeze on a > 4.0 branch or on trunk; is who it is that has to then merge and work with > multiple branches. > > Where that small but additional effort is placed I think becomes a signal to > what the community values most: new features or stability. > > I think most folk would vote for stability, so why not give this approach a > go and to learn from it. > It also creates an incentive to make the feature-freeze period as short as > possible, moving us towards an eventual goal of not needing to feature-freeze > at all. > > regards, > Mick > > - > 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
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 easier to discuss these things more genuinely after trying it out. One of the differences in the branching approaches: to feature-freeze on a 4.0 branch or on trunk; is who it is that has to then merge and work with multiple branches. Where that small but additional effort is placed I think becomes a signal to what the community values most: new features or stability. I think most folk would vote for stability, so why not give this approach a go and to learn from it. It also creates an incentive to make the feature-freeze period as short as possible, moving us towards an eventual goal of not needing to feature-freeze at all. regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
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 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 > 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 > > 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 > > >> 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 > > >> 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
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 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 > 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 > > > 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 > >> 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 > >> 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 > 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 > 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
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 very stable 4.0. That's a lot of committer head count already. I don't remember much community call to action in the past with regard to getting folks testing releases with real workloads. If we want help, it's on us to ask. Making it as easy as possible to test stuff out and get feedback is also on us. Banning folks from committing to trunk isn't solving the main problem: it's still pretty difficult to get involved. We need to lower the barrier to entry for setting & tearing down test clusters. We also need to recruit community members to be part of a QA feedback cycle. Once folks are in, keeping them involved for multiple iterations will improve their ability to give feedback. The nice part is, if we do it right, eventually maybe those folks will commit some code and become committers down the line. On Mon, Jul 9, 2018 at 11:31 AM sankalp kohli 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 > 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 > > 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 > > 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 > > >> 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 > > >> 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
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. 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 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 > 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 >> 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 >> 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 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 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 >> wrote: >> >>> Does anyone has any more feedback on this? >>> On Jul 4, 2018, at 05:36, Aleksey Yeshchenko >> wrote: For
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 what has already happened. On Mon, Jul 9, 2018 at 11:25 AM Jeremy Hanna 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 > 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 > 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 > >> 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 > >> 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 > wrote: > > > 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 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 >>> > > wrote: > >> > > We propose that between the
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 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 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 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 >> 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 >> 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 wrote: > 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 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 >> > 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 < >>
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 (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 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 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 > > 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 > > 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 > > > > 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 > > > > 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: > > > >
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 -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 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 > 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 > 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 > > > 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 > > > 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
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 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 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 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 > > 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 > > 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 > > > > wrote: > > > > > > > > > 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 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 > > > > > > > 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
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 Apache project. On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 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 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 > > wrote: > > > > > 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 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 > > > 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 > > > >> 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 > > > >>> 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=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE= > > > > > > >>> > > > >
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 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 > wrote: > > > 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 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 > > 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 > > >> 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 > > >>> 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=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE= > > > > >>> > > > > Jon > > > > > > On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie > > > > > 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 < >
Register now for ApacheCon and save $250
Greetings, Apache software enthusiasts! (You’re getting this because you’re on one or more dev@ or users@ lists for some Apache Software Foundation project.) ApacheCon North America, in Montreal, is now just 80 days away, and early bird prices end in just two weeks - on July 21. Prices will be going up from $550 to $800 so register NOW to save $250, at http://apachecon.com/acna18 And don’t forget to reserve your hotel room. We have negotiated a special rate and the room block closes August 24. http://www.apachecon.com/acna18/venue.html Our schedule includes over 100 talks and we’ll be featuring talks from dozens of ASF projects., We have inspiring keynotes from some of the brilliant members of our community and the wider tech space, including: * Myrle Krantz, PMC chair for Apache Fineract, and leader in the open source financing space * Cliff Schmidt, founder of Literacy Bridge (now Amplio) and creator of the Talking Book project * Bridget Kromhout, principal cloud developer advocate at Microsoft * Euan McLeod, Comcast engineer, and pioneer in streaming video We’ll also be featuring tracks for Geospatial science, Tomcat, Cloudstack, and Big Data, as well as numerous other fields where Apache software is leading the way. See the full schedule at http://apachecon.com/acna18/schedule.html As usual we’ll be running our Apache BarCamp, the traditional ApacheCon Hackathon, and the Wednesday evening Lighting Talks, too, so you’ll want to be there. Register today at http://apachecon.com/acna18 and we’ll see you in Montreal! -- Rich Bowen VP, Conferences, The Apache Software Foundation h...@apachecon.com @ApacheCon - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[VOTE FAILED - VETO] Release Apache Cassandra 2.2.13
This sha fails to build JDK7. If built on JDK8, which is what I did erroneously, the release fails with JDK7 runtime in AntiCompactionTest. In going through a round of test builds, it appears we have a problem with the CASSANDRA-14423 commit calling a JDK8-only String.join(). I'm vetoing this release. Kind regards, Michael On 07/04/2018 06:18 AM, kurt greaves wrote: > Actually taking back my +1, seems like we've got a fair amount of dtests > (at least 7) failing consistently on 2.2, and another one that's very flaky. > Last completed runs are here: > https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-2.2-dtest/116/testReport/ > https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-2.2-dtest-large/68/testReport/ > > Seeing as we committed to green tests at some point we should probably look > into these. > > Also yay for the test results analyzer not working. > > On 4 July 2018 at 09:06, Stefan Podkowinski wrote: > >> +1 >> >> On 02.07.2018 22:10, Michael Shuler wrote: >>> I propose the following artifacts for release as 2.2.13. >>> >>> sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645 >>> Git: >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> shortlog;h=refs/tags/2.2.13-tentative >>> >>> Artifacts: >>> https://repository.apache.org/content/repositories/ >> orgapachecassandra-1159/org/apache/cassandra/apache-cassandra/2.2.13/ >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/ >> orgapachecassandra-1159/ >>> >>> The Debian and RPM packages are available here: >>> http://people.apache.org/~mshuler/ >>> >>> The vote will be open for 72 hours (longer if needed). >>> >>> [1]: (CHANGES.txt) >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative >>> >>> [2]: (NEWS.txt) >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> blob_plain;f=NEWS.txt;hb=refs/tags/2.2.13-tentative >>> >>> >> >> - >> 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
[VOTE FAILED] Release Apache Cassandra 3.0.17
Based on the CASSANDRA-14555 notes and revert of the CASSANDRA-14252 from the cassandra-3.0/3.11 branches, I'm also a -1 for release. Kind regards, Michael On 07/03/2018 02:14 AM, Sam Tunnicliffe wrote: > -1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the > effect on streaming is verified. The concern is that the snitch change > could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for > this. > > > On 3 July 2018 at 04:02, Nate McCall wrote: > >> +1 >> >> On Tue, Jul 3, 2018 at 8:10 AM, Michael Shuler >> wrote: >>> I propose the following artifacts for release as 3.0.17. >>> >>> sha1: c4e6cd2a1aca84a88983192368bbcd4c8887c8b2 >>> Git: >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> shortlog;h=refs/tags/3.0.17-tentative >>> Artifacts: >>> https://repository.apache.org/content/repositories/ >> orgapachecassandra-1160/org/apache/cassandra/apache-cassandra/3.0.17/ >>> Staging repository: >>> https://repository.apache.org/content/repositories/ >> orgapachecassandra-1160/ >>> >>> The Debian and RPM packages are available here: >>> http://people.apache.org/~mshuler/ >>> >>> The vote will be open for 72 hours (longer if needed). >>> >>> [1]: (CHANGES.txt) >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative >>> [2]: (NEWS.txt) >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> blob_plain;f=NEWS.txt;hb=refs/tags/3.0.17-tentative >>> >>> -- >>> Michael - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[VOTE FAILED] Release Apache Cassandra 3.11.3
Based on the CASSANDRA-14555 notes and revert of the CASSANDRA-14252 from the cassandra-3.0/3.11 branches, I'm also a -1 for release. Kind regards, Michael On 07/03/2018 02:14 AM, Sam Tunnicliffe wrote: > -1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the > effect on streaming is verified. The concern is that the snitch change > could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for > this. > > > On 3 July 2018 at 04:02, Nate McCall wrote: > >> +1 >> >> On Tue, Jul 3, 2018 at 8:11 AM, Michael Shuler >> wrote: >>> I propose the following artifacts for release as 3.11.3. >>> >>> sha1: aed1b5fdf1e953d19bdd021ba603618772208cdd >>> Git: >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> shortlog;h=refs/tags/3.11.3-tentative >>> Artifacts: >>> https://repository.apache.org/content/repositories/ >> orgapachecassandra-1161/org/apache/cassandra/apache-cassandra/3.11.3/ >>> Staging repository: >>> https://repository.apache.org/content/repositories/ >> orgapachecassandra-1161/ >>> >>> The Debian and RPM packages are available here: >>> http://people.apache.org/~mshuler/ >>> >>> The vote will be open for 72 hours (longer if needed). >>> >>> [1]: (CHANGES.txt) >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative >>> [2]: (NEWS.txt) >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >> blob_plain;f=NEWS.txt;hb=refs/tags/3.11.3-tentative >>> >>> -- >>> Michael - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
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, 2018 at 5:01 PM Sankalp Kohli wrote: > 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 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 > 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 > >> 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 > >>> 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=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE= > > >>> > > Jon > > > On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie > > 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 > >>> > >>> > > 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
