Re: 4.0 alpha before apachecon?
Quick update on 4.0-alpha1 builds: - tar artifacts are published to maven[0] and sha d4054e0c tagged as 4.0-alpha1-tentative (thanks to Marcus Eriksson for asking this morning to look at a cassandra-diff PR for maven publish, which gave me a fresh idea on fixing .m2/settings.xml for new-laptop publish problems.. Fix worked!) - debs built locally, but upload to people.a.o failed, which we've documented a change for this to go to a new svn pre-release location, but I need to work this out in the release prep. - rpm upload to new svn location, too, once debs are done. Once I have the packages uploaded, we can start a (quick?) vote! I'll have some time to keep banging on the uploads later this afternoon and see how far I can get. I'm on a mobile hotspot with a decent connection at the moment :) [0] https://repository.apache.org/content/repositories/orgapachecassandra-1174/org/apache/cassandra/apache-cassandra/4.0-alpha1/ Michael On 8/29/19 2:30 PM, Joseph Lynch wrote: We hashed this out a bit in slack and I think the current rough consensus (please speak up if you don't agree) is that we update our release guidelines [1] to allow API changes between alpha and beta as the common artifact is useful for testing and we will probably end up finding API breakage while testing that must be fixed. Benedict helped out by creating 4.0-alpha [2] and 4.0-beta [3] fix versions so we can track what tickets are (roughly) blocking the next alpha/beta release. If you feel that something you're working on should block the alpha or the beta please help out and tag it with the proper fix version. The idea is that we know which outstanding tickets exist and are impacting the next alpha/beta, even if we ignore it and cut anyways at least we can separate "this has to happen before beta" from "this has to happen before release candidates". I think the next decision is should we just cut 4.0-alpha1 now given that Michael has some cycles regardless of the known issues and start using the new fix versions for the 4.0-alpha2 release? I personally feel we should cut 4.0-alpha1 with every imaginable "expect this release to break" disclaimer and start working towards 4.0-alpha2. [1] https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-alpha [3] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-beta What do people think? -Joey On Wed, Aug 28, 2019 at 10:58 AM Michael Shuler wrote: Thanks for the reminder :) I have a few days of availability to prep a 4.0 alpha release. It's an alpha, so I don't have a problem with known issues needing work. I will have an internet-less period of time starting roughly Tuesday 9/3 through about Friday 9/13. I might get lucky and have a little network access in the middle of that time, but I'm not counting on it. -- Michael On 8/28/19 10:51 AM, Jon Haddad wrote: Hey folks, I think it's time we cut a 4.0 alpha release. Before I put up a vote thread, is there a reason not to have a 4.0 alpha before ApacheCon / Cassandra Summit? There's a handful of small issues that I should be done for 4.0 (client list in virtual tables, dynamic snitch improvements, fixing token counts), I'm not trying to suggest we don't include them, but they're small enough I think it's OK to merge them in following the first alpha. Jon - 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
Re: 4.0 alpha before apachecon?
Not really important IMO if we do or do not cut a new branch yet. So let’s hold off? But as mentioned on Slack, I really like the idea of cutting an alpha now, with clear understanding that the API will still slightly change before the 4.0-GA. There is enough complete work in trunk that will *not* change between now and GA that could benefit from user testing already. > On 30 Aug 2019, at 12:46, Mick Semb Wever wrote: > > >> >> Let's just pull the trigger on it. We know there are a couple of rough >> edges, but that is the point of an alpha. > > > Is the idea to also cut 2.2.15, 3.0.19, and 3.11.5, at the same time as > 4.0-alpha1 ? > > (Michael, have you the cycles for this?) > > 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: 4.0 alpha before apachecon?
> > Let's just pull the trigger on it. We know there are a couple of rough > edges, but that is the point of an alpha. Is the idea to also cut 2.2.15, 3.0.19, and 3.11.5, at the same time as 4.0-alpha1 ? (Michael, have you the cycles for this?) regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: 4.0 alpha before apachecon?
Agreed. There's no point in a branch if we aren't committing new features to trunk, and I don't think we should yet. On Thu, Aug 29, 2019 at 3:50 PM Dinesh Joshi wrote: > We should not branch trunk at least until the RC is out. > > Dinesh > > > On Aug 29, 2019, at 3:32 PM, Sankalp Kohli > wrote: > > > > I do not think we should branch and is -1 on it. The reason we have > trunk frozen was for our focus to be on 4.0. I think we still need that > focus till a few more releases like these. > > > >> On Aug 30, 2019, at 12:24 AM, Nate McCall wrote: > >> > >> On Fri, Aug 30, 2019 at 10:11 AM Benedict Elliott Smith < > bened...@apache.org> > >> wrote: > >> > >>> > >>> Seems to make sense to branch, right? > >>> > >>> Feels like a good line in the sand. +1 > > > > - > > 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: 4.0 alpha before apachecon?
We should not branch trunk at least until the RC is out. Dinesh > On Aug 29, 2019, at 3:32 PM, Sankalp Kohli wrote: > > I do not think we should branch and is -1 on it. The reason we have trunk > frozen was for our focus to be on 4.0. I think we still need that focus till > a few more releases like these. > >> On Aug 30, 2019, at 12:24 AM, Nate McCall wrote: >> >> On Fri, Aug 30, 2019 at 10:11 AM Benedict Elliott Smith >> >> wrote: >> >>> >>> Seems to make sense to branch, right? >>> >>> Feels like a good line in the sand. +1 > > - > 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: 4.0 alpha before apachecon?
I do not think we should branch and is -1 on it. The reason we have trunk frozen was for our focus to be on 4.0. I think we still need that focus till a few more releases like these. > On Aug 30, 2019, at 12:24 AM, Nate McCall wrote: > > On Fri, Aug 30, 2019 at 10:11 AM Benedict Elliott Smith > wrote: > >> >>Seems to make sense to branch, right? >> >> Feels like a good line in the sand. +1 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: 4.0 alpha before apachecon?
On Fri, Aug 30, 2019 at 10:11 AM Benedict Elliott Smith wrote: > > Seems to make sense to branch, right? > > Feels like a good line in the sand. +1
Re: 4.0 alpha before apachecon?
Seems to make sense to branch, right? On Thu, Aug 29, 2019 at 11:10 PM +0100, "sankalp kohli" wrote: Will we cut alpha1 and later alpha releases from trunk or create a new branch? On Friday, August 30, 2019, Nate McCall wrote: > > > > > > I think the next decision is should we just cut 4.0-alpha1 now given > > that Michael has some cycles regardless of the known issues and start > > using the new fix versions for the 4.0-alpha2 release? I personally > > feel we should cut 4.0-alpha1 with every imaginable "expect this > > release to break" disclaimer and start working towards 4.0-alpha2. > > > > Let's just pull the trigger on it. We know there are a couple of rough > edges, but that is the point of an alpha. >
Re: 4.0 alpha before apachecon?
Will we cut alpha1 and later alpha releases from trunk or create a new branch? On Friday, August 30, 2019, Nate McCall wrote: > > > > > > I think the next decision is should we just cut 4.0-alpha1 now given > > that Michael has some cycles regardless of the known issues and start > > using the new fix versions for the 4.0-alpha2 release? I personally > > feel we should cut 4.0-alpha1 with every imaginable "expect this > > release to break" disclaimer and start working towards 4.0-alpha2. > > > > Let's just pull the trigger on it. We know there are a couple of rough > edges, but that is the point of an alpha. >
Re: 4.0 alpha before apachecon?
> > > I think the next decision is should we just cut 4.0-alpha1 now given > that Michael has some cycles regardless of the known issues and start > using the new fix versions for the 4.0-alpha2 release? I personally > feel we should cut 4.0-alpha1 with every imaginable "expect this > release to break" disclaimer and start working towards 4.0-alpha2. > Let's just pull the trigger on it. We know there are a couple of rough edges, but that is the point of an alpha.
Re: 4.0 alpha before apachecon?
We hashed this out a bit in slack and I think the current rough consensus (please speak up if you don't agree) is that we update our release guidelines [1] to allow API changes between alpha and beta as the common artifact is useful for testing and we will probably end up finding API breakage while testing that must be fixed. Benedict helped out by creating 4.0-alpha [2] and 4.0-beta [3] fix versions so we can track what tickets are (roughly) blocking the next alpha/beta release. If you feel that something you're working on should block the alpha or the beta please help out and tag it with the proper fix version. The idea is that we know which outstanding tickets exist and are impacting the next alpha/beta, even if we ignore it and cut anyways at least we can separate "this has to happen before beta" from "this has to happen before release candidates". I think the next decision is should we just cut 4.0-alpha1 now given that Michael has some cycles regardless of the known issues and start using the new fix versions for the 4.0-alpha2 release? I personally feel we should cut 4.0-alpha1 with every imaginable "expect this release to break" disclaimer and start working towards 4.0-alpha2. [1] https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-alpha [3] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-beta What do people think? -Joey On Wed, Aug 28, 2019 at 10:58 AM Michael Shuler wrote: > > Thanks for the reminder :) I have a few days of availability to prep a > 4.0 alpha release. It's an alpha, so I don't have a problem with known > issues needing work. > > I will have an internet-less period of time starting roughly Tuesday 9/3 > through about Friday 9/13. I might get lucky and have a little network > access in the middle of that time, but I'm not counting on it. > > -- > Michael > > On 8/28/19 10:51 AM, Jon Haddad wrote: > > Hey folks, > > > > I think it's time we cut a 4.0 alpha release. Before I put up a vote > > thread, is there a reason not to have a 4.0 alpha before ApacheCon / > > Cassandra Summit? > > > > There's a handful of small issues that I should be done for 4.0 (client > > list in virtual tables, dynamic snitch improvements, fixing token counts), > > I'm not trying to suggest we don't include them, but they're small enough I > > think it's OK to merge them in following the first alpha. > > > > Jon > > > > - > 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: 4.0 alpha before apachecon?
Thanks for the reminder :) I have a few days of availability to prep a 4.0 alpha release. It's an alpha, so I don't have a problem with known issues needing work. I will have an internet-less period of time starting roughly Tuesday 9/3 through about Friday 9/13. I might get lucky and have a little network access in the middle of that time, but I'm not counting on it. -- Michael On 8/28/19 10:51 AM, Jon Haddad wrote: Hey folks, I think it's time we cut a 4.0 alpha release. Before I put up a vote thread, is there a reason not to have a 4.0 alpha before ApacheCon / Cassandra Summit? There's a handful of small issues that I should be done for 4.0 (client list in virtual tables, dynamic snitch improvements, fixing token counts), I'm not trying to suggest we don't include them, but they're small enough I think it's OK to merge them in following the first alpha. Jon - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: 4.0 alpha before apachecon?
Yes we do. It's one of the reasons I've spent about a lot of (thousands?) hours working on tlp-stress and tlp-cluster in the last 2 years. I shared some progress on this a little ways back. I'll send out a separate email soon with updates, since we just merged in a *lot* of features that will help with testing. On Wed, Aug 28, 2019 at 10:52 AM Dinesh Joshi wrote: > +1 on cutting an alpha and having a clear, documented test plan[1] for > alpha. We need volunteers to drive the test plan, though. :) > > Thanks, > > Dinesh > > [1] > https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > > > On Aug 28, 2019, at 10:27 AM, Jon Haddad wrote: > > > > Regarding the dynamic snitch improvements, it's gone through several > rounds > > of review already and there's been significant testing of it. Regarding > > the token change, switching a number from 256 -> 16 isn't so invasive > that > > we shouldn't do it. There's a little extra work that needs to be done > > there ideally to ensure safety, but it's again small enough where it > > shouldn't be too big of a problem imo. Both current implementations (256 > > tokens + our insanely over memory allocating dynamic snitch) limit the > > ability of people to run large clusters, harming both availability and > > performance. It's been extremely harmful for Cassandra's reputation and > > I'd really like it if we could ship something where I don't have to > > constantly apologize to people I'm trying to help for the land mine > > defaults we put out there. > > > > To your point, I agree as a community we're lacking in an open, well > > documented and up to date plan, and it needs to be addressed. I think > the > > virtual meetings idea held at a regular might help a bit with that, I > > intend on participating there. > > > > > > On Wed, Aug 28, 2019 at 9:52 AM Joshua McKenzie > > wrote: > > > >>> > >>> dynamic snitch improvements, fixing token counts > >> > >> > >> > >>> they're small enough > >> > >> > >> By what axis of measurement out of curiosity? Risk to re-test and > validate > >> a final artifact? Do we have a more clear understanding of what testing > has > >> taken place across the community? > >> > >> The last I saw, our documented test plan > >> < > >> > https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > >>> > >> hasn't > >> been maintained or kept up to date > >> < > >> > https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA > >>> . > >> Is there another artifact reflecting what testing people have in flight > to > >> better reflect what risk of needing to re-test we have from these (and > >> other) post-freeze changes? > >> > >> > >> > >> On Wed, Aug 28, 2019 at 11:52 AM Jon Haddad wrote: > >> > >>> Hey folks, > >>> > >>> I think it's time we cut a 4.0 alpha release. Before I put up a vote > >>> thread, is there a reason not to have a 4.0 alpha before ApacheCon / > >>> Cassandra Summit? > >>> > >>> There's a handful of small issues that I should be done for 4.0 (client > >>> list in virtual tables, dynamic snitch improvements, fixing token > >> counts), > >>> I'm not trying to suggest we don't include them, but they're small > >> enough I > >>> think it's OK to merge them in following the first alpha. > >>> > >>> Jon > >>> > >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: 4.0 alpha before apachecon?
+1 on cutting an alpha and having a clear, documented test plan[1] for alpha. We need volunteers to drive the test plan, though. :) Thanks, Dinesh [1] https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > On Aug 28, 2019, at 10:27 AM, Jon Haddad wrote: > > Regarding the dynamic snitch improvements, it's gone through several rounds > of review already and there's been significant testing of it. Regarding > the token change, switching a number from 256 -> 16 isn't so invasive that > we shouldn't do it. There's a little extra work that needs to be done > there ideally to ensure safety, but it's again small enough where it > shouldn't be too big of a problem imo. Both current implementations (256 > tokens + our insanely over memory allocating dynamic snitch) limit the > ability of people to run large clusters, harming both availability and > performance. It's been extremely harmful for Cassandra's reputation and > I'd really like it if we could ship something where I don't have to > constantly apologize to people I'm trying to help for the land mine > defaults we put out there. > > To your point, I agree as a community we're lacking in an open, well > documented and up to date plan, and it needs to be addressed. I think the > virtual meetings idea held at a regular might help a bit with that, I > intend on participating there. > > > On Wed, Aug 28, 2019 at 9:52 AM Joshua McKenzie > wrote: > >>> >>> dynamic snitch improvements, fixing token counts >> >> >> >>> they're small enough >> >> >> By what axis of measurement out of curiosity? Risk to re-test and validate >> a final artifact? Do we have a more clear understanding of what testing has >> taken place across the community? >> >> The last I saw, our documented test plan >> < >> https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans >>> >> hasn't >> been maintained or kept up to date >> < >> https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA >>> . >> Is there another artifact reflecting what testing people have in flight to >> better reflect what risk of needing to re-test we have from these (and >> other) post-freeze changes? >> >> >> >> On Wed, Aug 28, 2019 at 11:52 AM Jon Haddad wrote: >> >>> Hey folks, >>> >>> I think it's time we cut a 4.0 alpha release. Before I put up a vote >>> thread, is there a reason not to have a 4.0 alpha before ApacheCon / >>> Cassandra Summit? >>> >>> There's a handful of small issues that I should be done for 4.0 (client >>> list in virtual tables, dynamic snitch improvements, fixing token >> counts), >>> I'm not trying to suggest we don't include them, but they're small >> enough I >>> think it's OK to merge them in following the first alpha. >>> >>> Jon >>> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: 4.0 alpha before apachecon?
Regarding the dynamic snitch improvements, it's gone through several rounds of review already and there's been significant testing of it. Regarding the token change, switching a number from 256 -> 16 isn't so invasive that we shouldn't do it. There's a little extra work that needs to be done there ideally to ensure safety, but it's again small enough where it shouldn't be too big of a problem imo. Both current implementations (256 tokens + our insanely over memory allocating dynamic snitch) limit the ability of people to run large clusters, harming both availability and performance. It's been extremely harmful for Cassandra's reputation and I'd really like it if we could ship something where I don't have to constantly apologize to people I'm trying to help for the land mine defaults we put out there. To your point, I agree as a community we're lacking in an open, well documented and up to date plan, and it needs to be addressed. I think the virtual meetings idea held at a regular might help a bit with that, I intend on participating there. On Wed, Aug 28, 2019 at 9:52 AM Joshua McKenzie wrote: > > > > dynamic snitch improvements, fixing token counts > > > > > they're small enough > > > By what axis of measurement out of curiosity? Risk to re-test and validate > a final artifact? Do we have a more clear understanding of what testing has > taken place across the community? > > The last I saw, our documented test plan > < > https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > > > hasn't > been maintained or kept up to date > < > https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA > >. > Is there another artifact reflecting what testing people have in flight to > better reflect what risk of needing to re-test we have from these (and > other) post-freeze changes? > > > > On Wed, Aug 28, 2019 at 11:52 AM Jon Haddad wrote: > > > Hey folks, > > > > I think it's time we cut a 4.0 alpha release. Before I put up a vote > > thread, is there a reason not to have a 4.0 alpha before ApacheCon / > > Cassandra Summit? > > > > There's a handful of small issues that I should be done for 4.0 (client > > list in virtual tables, dynamic snitch improvements, fixing token > counts), > > I'm not trying to suggest we don't include them, but they're small > enough I > > think it's OK to merge them in following the first alpha. > > > > Jon > > >
Re: 4.0 alpha before apachecon?
> > dynamic snitch improvements, fixing token counts > they're small enough By what axis of measurement out of curiosity? Risk to re-test and validate a final artifact? Do we have a more clear understanding of what testing has taken place across the community? The last I saw, our documented test plan <https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans> hasn't been maintained or kept up to date <https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA>. Is there another artifact reflecting what testing people have in flight to better reflect what risk of needing to re-test we have from these (and other) post-freeze changes? On Wed, Aug 28, 2019 at 11:52 AM Jon Haddad wrote: > Hey folks, > > I think it's time we cut a 4.0 alpha release. Before I put up a vote > thread, is there a reason not to have a 4.0 alpha before ApacheCon / > Cassandra Summit? > > There's a handful of small issues that I should be done for 4.0 (client > list in virtual tables, dynamic snitch improvements, fixing token counts), > I'm not trying to suggest we don't include them, but they're small enough I > think it's OK to merge them in following the first alpha. > > Jon >
4.0 alpha before apachecon?
Hey folks, I think it's time we cut a 4.0 alpha release. Before I put up a vote thread, is there a reason not to have a 4.0 alpha before ApacheCon / Cassandra Summit? There's a handful of small issues that I should be done for 4.0 (client list in virtual tables, dynamic snitch improvements, fixing token counts), I'm not trying to suggest we don't include them, but they're small enough I think it's OK to merge them in following the first alpha. Jon
