Re: [VOTE] Release Apache Cassandra 3.0.9
+1 On Fri, Sep 16, 2016 at 12:31 AM, Sam Tunnicliffe wrote: > +1 > > On 15 Sep 2016 19:58, "Jake Luciani" wrote: > > > I propose the following artifacts for release as 3.0.9. > > > > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 > > Git: > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > > shortlog;h=refs/tags/3.0.9-tentative > > Artifacts: > > https://repository.apache.org/content/repositories/ > > orgapachecassandra-1124/org/apache/cassandra/apache-cassandra/3.0.9/ > > Staging repository: > > https://repository.apache.org/content/repositories/ > > orgapachecassandra-1124/ > > > > The artifacts as well as the debian package are also available here: > > http://people.apache.org/~jake > > > > The vote will be open for 72 hours (longer if needed). > > > > [1]: https://goo.gl/JKkE05 (CHANGES.txt) > > [2]: https://goo.gl/Hi8X71 (NEWS.txt) > > >
Re: Proposal - 3.5.1
As probably pretty much everyone at this point, I agree the tick-tock experiment isn't working as well as it should and that it's probably worth course correcting. I happen to have been thinking about this quite a bit already as it turns out so I'm going to share my reasoning and suggestion below, even though it's going to be pretty long, in the hope it can be useful (and if it isn't, so be it). My current thinking is that a good cycle should accommodate 2 main constraints: 1) be useful for users 2) be realistic/limit friction on the development side and let me develop what I mean by both points slightly first. I think users mostly want 2 things out of the release schedule: they want a clearly labeled stable branch to know what they should run into production, and they want new features and improvements. Let me clarify that different users will want those 2 in different degrees and with variation over time, but I believe it's mainly some combination of those. On the development side, I don't think it's realistic to expect more than 2/3 branches/series to be supported at any one time (not going to argue that, let's call it a professional opinion). I also think accumulating new work for any meaningful length of time before releasing, as we used to do, is bad as it pushes devs to rush things to meet a given release deadline as they don't want to wait for the next one. This in turn impacts quality and creates unnecessary drama. It's also good imo to have a clear policy regarding where a given work can go (having to debate on each ticket on which branch it should go is a waste of dev time). With those "goals" in mind, I'll note that: - the fixed _and_ short cadence of tick-tock is imo very good, in particular in (but not limited to) avoiding the 'accumulate unreleased stuffs' problem. - we have ample evidence that stuffs don't get truly stable until they get only bug fixes for a few months. Which doesn't mean at all that we shouldn't continue to make progress on increasing the quality of new code btw. - Simple is also a great quality of a release cycle. I think we should try to define what's truly important to achieve (my opinion on that is above) and do the simplest thing that achieve that. This does imply the release cycle won't make the coffee, but that's alright, it probably shouldn't anyway. In light of all this, my suggesting for a release cycle woud be: - To have 3 branches: 'features', 'testing' and 'stable', with an X month rotation: 'features' becomes 'testing' after X months and then 'stable' after X more, before getting EOL X months later. - The feature branch gets everything. The testing branch only gets bug fixes. The stable branch only gets critical bug fixes. And imo, we should be very strict on this (I acknowledge that there is sometimes a bit of subjectivity on whether something is a bug or an improvement, and if it's critical or not, but I think it's not that hard to get consensus if we're all reasonable (though it might worth agreeing on some rough but written guideline upfront)). - We release on a short and fixed cadence of Y month(s) for both the feature and testing branch. For the stable branch, given that it already had X months of only bug fixes during the testing phase, one can hope critical fixes will be fairly rare, less than 1 per Y period on average). Further, it's supposed to be stable and fixes are supposed to be critical, so doing hot-fix releases probably makes the most sense (though it probably only work if we're indeed strict on what is considered critical). And that's about it. I think it would believably achieve stability (with a clear label on which releases are stable), but also provide new features and improvements quickly for those that wants that. The testing phase is imo a necessary intermediate step to get the stable one. On thing to define is X and Y. For Y (the cadence of feature/testing), I think 1 or 2 months are the only options that make sense (less than 1 month is too fast, and more than 2 months is imo starting to get too long). For X, that's more debatable but it's open-source and we should recognize volunteers generally don't want to maintain things for too long either. My 2 is that 6 or 8 months are probably the best options here. We'd also have to put some numbering scheme on top of that, but that's not really the important part (the meaning is in the branch labels, not the numbers). To give just one possible option (and assuming X=6, Y=1), in January 2017 we could cut 4.0 as the start of both 'feature' and 'testing'. We'd then have 4.1, 4.2, ... on the 'feature' branch, and 4.0.1, 4.0.2, ... on the testing branch for the next 6 months. In July, we'd switch from 4.5 to 5.0, with that becoming the new 'feature' and 'testing' base. At the same time, we'd cut 4.0.6 from 4.0.5 as the new 'stable' branch. Hot-fix on that stable branch would be versioned 4.0.6.1, 4.0.6.2 and so on. Of course, there can be variat
Re: [VOTE] Release Apache Cassandra 3.0.9
+1 On Fri, Sep 16, 2016 at 5:56 AM, Sylvain Lebresne wrote: > +1 > > On Fri, Sep 16, 2016 at 12:31 AM, Sam Tunnicliffe wrote: > > > +1 > > > > On 15 Sep 2016 19:58, "Jake Luciani" wrote: > > > > > I propose the following artifacts for release as 3.0.9. > > > > > > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 > > > Git: > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > > > shortlog;h=refs/tags/3.0.9-tentative > > > Artifacts: > > > https://repository.apache.org/content/repositories/ > > > orgapachecassandra-1124/org/apache/cassandra/apache-cassandra/3.0.9/ > > > Staging repository: > > > https://repository.apache.org/content/repositories/ > > > orgapachecassandra-1124/ > > > > > > The artifacts as well as the debian package are also available here: > > > http://people.apache.org/~jake > > > > > > The vote will be open for 72 hours (longer if needed). > > > > > > [1]: https://goo.gl/JKkE05 (CHANGES.txt) > > > [2]: https://goo.gl/Hi8X71 (NEWS.txt) > > > > > >
Re: [VOTE] Release Apache Cassandra 3.0.9
+1 On Thu, Sep 15, 2016 at 1:57 PM, Jake Luciani wrote: > I propose the following artifacts for release as 3.0.9. > > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/3.0.9-tentative > Artifacts: > https://repository.apache.org/content/repositories/ > orgapachecassandra-1124/org/apache/cassandra/apache-cassandra/3.0.9/ > Staging repository: > https://repository.apache.org/content/repositories/ > orgapachecassandra-1124/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~jake > > The vote will be open for 72 hours (longer if needed). > > [1]: https://goo.gl/JKkE05 (CHANGES.txt) > [2]: https://goo.gl/Hi8X71 (NEWS.txt) >
Re: Proposal - 3.5.1
I've worked on a few projects where we've had a branch that new stuff went in before merging to master / trunk. What you've described reminds me a lot of git-flow (http://nvie.com/posts/a-successful-git-branching-model/) although not quite the same. I'll be verbose in this email to minimize the reader's assumptions. The goals of the release cycle should be (in descending order of priority): 1. Minimize bugs introduced through change 2. Allow the codebase to iterate quickly 3. Not get caught up in a ton of back porting bug fixes There is significant benefit to having a releasable trunk. This is different from a trunk which is constantly released. A releasable trunk simply means all tests should *always* pass and PMC & committers should feel confident that they could actually put it in prod for a project that actually matters. Having it always be releasable (all tests pass, etc) means people can at least test the DB on sample data or evaluate it before the release happens, and get feedback to the team when there are bugs. This is a different mentality from having a "features" branch, where it's implied that at times it's acceptable that it not be stable. The historical trend with the Cassandra codebase has been to test minimally, throw the code over the wall, and get feedback from people putting it in prod who run into issues. In my experience I have found a general purpose "features" branch to result in poorly quality codebases. It's shares a lot of the same problems as the 1+ year release cycle did previously, with things getting merged in and then an attempt to stabilize later. Improving the state of testing in trunk will catch more bugs, satisfying #1, which naturally leads to #2, and by reducing bugs before they get released #3 will happen over time. My suggestion for a *supported* feature release every 3 months (could just as well be 4 or 6) mixed with Benedict's idea of frequent non-supported releases (tagged as alpha). Supported releases should get ~6 months worth of bug fixes, which if done right, will decrease over time due to a hopefully more stable codebase. I 100% agree with Mick that semver makes sense here, it's not just for frameworks. Major.Minor.Patch is well understood and is pretty standard throughout the world, I don't think we need to reinvent versioning. TL;DR: Release every 3 months Support for 6 Keep a stable trunk New features get merged into trunk but the standard for code quality and testing needs to be property defined as something closer to "production ready" rather than "let the poor user figure it out" Jon On Fri, Sep 16, 2016 at 3:05 AM Sylvain Lebresne wrote: > As probably pretty much everyone at this point, I agree the tick-tock > experiment > isn't working as well as it should and that it's probably worth course > correcting. I happen to have been thinking about this quite a bit already > as it > turns out so I'm going to share my reasoning and suggestion below, even > though > it's going to be pretty long, in the hope it can be useful (and if it > isn't, so > be it). > > My current thinking is that a good cycle should accommodate 2 main > constraints: > 1) be useful for users > 2) be realistic/limit friction on the development side > and let me develop what I mean by both points slightly first. > > I think users mostly want 2 things out of the release schedule: they want a > clearly labeled stable branch to know what they should run into production, > and > they want new features and improvements. Let me clarify that different > users > will want those 2 in different degrees and with variation over time, but I > believe it's mainly some combination of those. On the development side, I > don't > think it's realistic to expect more than 2/3 branches/series to be > supported at > any one time (not going to argue that, let's call it a professional > opinion). I > also think accumulating new work for any meaningful length of time before > releasing, as we used to do, is bad as it pushes devs to rush things to > meet a > given release deadline as they don't want to wait for the next one. This in > turn > impacts quality and creates unnecessary drama. It's also good imo to have a > clear policy regarding where a given work can go (having to debate on each > ticket on which branch it should go is a waste of dev time). > > With those "goals" in mind, I'll note that: > - the fixed _and_ short cadence of tick-tock is imo very good, in > particular in > (but not limited to) avoiding the 'accumulate unreleased stuffs' problem. > - we have ample evidence that stuffs don't get truly stable until they get > only > bug fixes for a few months. Which doesn't mean at all that we shouldn't > continue to make progress on increasing the quality of new code btw. > - Simple is also a great quality of a release cycle. I think we should try > to > define what's truly important to achieve (my opinion on that is above) > and do > the simplest thing that achie
Re: Proposal - 3.5.1
"The historical trend with the Cassandra codebase has been to test minimally, throw the code over the wall, and get feedback from people putting it in prod who run into issues." At the summit Brandon and a couple others were making fun over range tombstones from thrift https://issues.apache.org/jira/browse/CASSANDRA-5435 I added the thrift support based on code already in trunk. But there was something ugly bit in there and far on down the line someone else stuck with an edge case and had to fix it. Now, I actually added a number of tests, unit test, and nosetests. I am sure the range tombstones also had their own set of tests at the storage level. So as Brandon was making fun of me, I was thinking to myself, "Well I did not make the bug, I just made it possible for others to find it! So I am helping!" The next time I submit a thrift patch I am going to write 5x the unit tests jk :) On Fri, Sep 16, 2016 at 11:18 AM, Jonathan Haddad wrote: > I've worked on a few projects where we've had a branch that new stuff went > in before merging to master / trunk. What you've described reminds me a > lot of git-flow (http://nvie.com/posts/a-successful-git-branching-model/) > although not quite the same. I'll be verbose in this email to minimize the > reader's assumptions. > > The goals of the release cycle should be (in descending order of priority): > > 1. Minimize bugs introduced through change > 2. Allow the codebase to iterate quickly > 3. Not get caught up in a ton of back porting bug fixes > > There is significant benefit to having a releasable trunk. This is > different from a trunk which is constantly released. A releasable trunk > simply means all tests should *always* pass and PMC & committers should > feel confident that they could actually put it in prod for a project that > actually matters. Having it always be releasable (all tests pass, etc) > means people can at least test the DB on sample data or evaluate it before > the release happens, and get feedback to the team when there are bugs. > > This is a different mentality from having a "features" branch, where it's > implied that at times it's acceptable that it not be stable. The > historical trend with the Cassandra codebase has been to test minimally, > throw the code over the wall, and get feedback from people putting it in > prod who run into issues. In my experience I have found a general purpose > "features" branch to result in poorly quality codebases. It's shares a lot > of the same problems as the 1+ year release cycle did previously, with > things getting merged in and then an attempt to stabilize later. > > Improving the state of testing in trunk will catch more bugs, satisfying > #1, which naturally leads to #2, and by reducing bugs before they get > released #3 will happen over time. > > My suggestion for a *supported* feature release every 3 months (could just > as well be 4 or 6) mixed with Benedict's idea of frequent non-supported > releases (tagged as alpha). Supported releases should get ~6 months worth > of bug fixes, which if done right, will decrease over time due to a > hopefully more stable codebase. I 100% agree with Mick that semver makes > sense here, it's not just for frameworks. Major.Minor.Patch is well > understood and is pretty standard throughout the world, I don't think we > need to reinvent versioning. > > TL;DR: > Release every 3 months > Support for 6 > Keep a stable trunk > New features get merged into trunk but the standard for code quality and > testing needs to be property defined as something closer to "production > ready" rather than "let the poor user figure it out" > > Jon > > > > > > > > On Fri, Sep 16, 2016 at 3:05 AM Sylvain Lebresne > wrote: > > > As probably pretty much everyone at this point, I agree the tick-tock > > experiment > > isn't working as well as it should and that it's probably worth course > > correcting. I happen to have been thinking about this quite a bit already > > as it > > turns out so I'm going to share my reasoning and suggestion below, even > > though > > it's going to be pretty long, in the hope it can be useful (and if it > > isn't, so > > be it). > > > > My current thinking is that a good cycle should accommodate 2 main > > constraints: > > 1) be useful for users > > 2) be realistic/limit friction on the development side > > and let me develop what I mean by both points slightly first. > > > > I think users mostly want 2 things out of the release schedule: they > want a > > clearly labeled stable branch to know what they should run into > production, > > and > > they want new features and improvements. Let me clarify that different > > users > > will want those 2 in different degrees and with variation over time, but > I > > believe it's mainly some combination of those. On the development side, I > > don't > > think it's realistic to expect more than 2/3 branches/series to be > > supported at > > any one time (not going to argue that, let's call it a pro
Re: Proposal - 3.5.1
On Fri, Sep 16, 2016 at 10:18 AM, Jonathan Haddad wrote: > TL;DR: > Release every 3 months > Support for 6 > Keep a stable trunk > New features get merged into trunk but the standard for code quality and > testing needs to be property defined as something closer to "production > ready" rather than "let the poor user figure it out" > I like it. I think one of the data points from dick tock is that monthly releases are just too often. Quarterly is a better cadence. -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
Re: Proposal - 3.5.1
Sorry, in my TL;DR I forgot release frequent alphas (nightly / weekly / whatever schedule you want) On Fri, Sep 16, 2016 at 8:18 AM Jonathan Haddad wrote: > I've worked on a few projects where we've had a branch that new stuff went > in before merging to master / trunk. What you've described reminds me a > lot of git-flow (http://nvie.com/posts/a-successful-git-branching-model/) > although not quite the same. I'll be verbose in this email to minimize the > reader's assumptions. > > The goals of the release cycle should be (in descending order of priority): > > 1. Minimize bugs introduced through change > 2. Allow the codebase to iterate quickly > 3. Not get caught up in a ton of back porting bug fixes > > There is significant benefit to having a releasable trunk. This is > different from a trunk which is constantly released. A releasable trunk > simply means all tests should *always* pass and PMC & committers should > feel confident that they could actually put it in prod for a project that > actually matters. Having it always be releasable (all tests pass, etc) > means people can at least test the DB on sample data or evaluate it before > the release happens, and get feedback to the team when there are bugs. > > This is a different mentality from having a "features" branch, where it's > implied that at times it's acceptable that it not be stable. The > historical trend with the Cassandra codebase has been to test minimally, > throw the code over the wall, and get feedback from people putting it in > prod who run into issues. In my experience I have found a general purpose > "features" branch to result in poorly quality codebases. It's shares a lot > of the same problems as the 1+ year release cycle did previously, with > things getting merged in and then an attempt to stabilize later. > > Improving the state of testing in trunk will catch more bugs, satisfying > #1, which naturally leads to #2, and by reducing bugs before they get > released #3 will happen over time. > > My suggestion for a *supported* feature release every 3 months (could just > as well be 4 or 6) mixed with Benedict's idea of frequent non-supported > releases (tagged as alpha). Supported releases should get ~6 months worth > of bug fixes, which if done right, will decrease over time due to a > hopefully more stable codebase. I 100% agree with Mick that semver makes > sense here, it's not just for frameworks. Major.Minor.Patch is well > understood and is pretty standard throughout the world, I don't think we > need to reinvent versioning. > > TL;DR: > Release every 3 months > Support for 6 > Keep a stable trunk > New features get merged into trunk but the standard for code quality and > testing needs to be property defined as something closer to "production > ready" rather than "let the poor user figure it out" > > Jon > > > > > > > > On Fri, Sep 16, 2016 at 3:05 AM Sylvain Lebresne > wrote: > >> As probably pretty much everyone at this point, I agree the tick-tock >> experiment >> isn't working as well as it should and that it's probably worth course >> correcting. I happen to have been thinking about this quite a bit already >> as it >> turns out so I'm going to share my reasoning and suggestion below, even >> though >> it's going to be pretty long, in the hope it can be useful (and if it >> isn't, so >> be it). >> >> My current thinking is that a good cycle should accommodate 2 main >> constraints: >> 1) be useful for users >> 2) be realistic/limit friction on the development side >> and let me develop what I mean by both points slightly first. >> >> I think users mostly want 2 things out of the release schedule: they want >> a >> clearly labeled stable branch to know what they should run into >> production, >> and >> they want new features and improvements. Let me clarify that different >> users >> will want those 2 in different degrees and with variation over time, but I >> believe it's mainly some combination of those. On the development side, I >> don't >> think it's realistic to expect more than 2/3 branches/series to be >> supported at >> any one time (not going to argue that, let's call it a professional >> opinion). I >> also think accumulating new work for any meaningful length of time before >> releasing, as we used to do, is bad as it pushes devs to rush things to >> meet a >> given release deadline as they don't want to wait for the next one. This >> in >> turn >> impacts quality and creates unnecessary drama. It's also good imo to have >> a >> clear policy regarding where a given work can go (having to debate on each >> ticket on which branch it should go is a waste of dev time). >> >> With those "goals" in mind, I'll note that: >> - the fixed _and_ short cadence of tick-tock is imo very good, in >> particular in >> (but not limited to) avoiding the 'accumulate unreleased stuffs' >> problem. >> - we have ample evidence that stuffs don't get truly stable until they get >> only >> bug fixes for a few
Re: Proposal - 3.5.1
On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad wrote: > > This is a different mentality from having a "features" branch, where it's > implied that at times it's acceptable that it not be stable. I absolutely never implied that, though I willingly admit my choice of branch names may be to blame. I 100% agree that no releases should be done without a green test board moving forward and if something was implicit in my 'feature' branch proposal, it was that. Where we might not be in the same page is that I just don't believe it's reasonable to expect the project will get any time soon in a state where even a green test board release (with new features) meets the "can be confidently put into production". I'm not even sure it's reasonable to expect from *any* software, and even less so for an open-source project based on volunteering. Not saying it wouldn't be amazing, it would, I just don't believe it's realistic. In a way, the reason why I think tick-tock doesn't work is *exactly* because it's based on that unrealistic assumption. Of course, I suppose that's kind of my opinion. I'm sure some will think that the "historical trend" of release instability is simply due to a lack of effort (obviously Cassandra developers don't give a shit about users, that must the simplest explanation).
Re: Proposal - 3.5.1
What I was trying to suggest is that the *goal* of trunk should always be releasable, and the alpha releases would be the means of testing that. If the goal is to always be releasable, we move towards achieving that goal by improving modularity, test coverage and test granularity. Yes, it's very difficult to prove a piece of software is completely free of bugs and I wouldn't expect NASA to put Cassandra on the space shuttle. That said, by prioritizing stability in the software development process up front, the cost of maintaining older branches over time will decrease and the velocity of the project will increase - which was the original goal of Tick Tock. Jon On Fri, Sep 16, 2016 at 9:04 AM Sylvain Lebresne wrote: > On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad > wrote: > > > > > This is a different mentality from having a "features" branch, where it's > > implied that at times it's acceptable that it not be stable. > > > I absolutely never implied that, though I willingly admit my choice of > branch > names may be to blame. I 100% agree that no releases should be done > without a green test board moving forward and if something was implicit > in my 'feature' branch proposal, it was that. > > Where we might not be in the same page is that I just don't believe it's > reasonable to expect the project will get any time soon in a state where > even a green test board release (with new features) meets the "can be > confidently put into production". I'm not even sure it's reasonable to > expect from *any* software, and even less so for an open-source > project based on volunteering. Not saying it wouldn't be amazing, it > would, I just don't believe it's realistic. In a way, the reason why I > think > tick-tock doesn't work is *exactly* because it's based on that unrealistic > assumption. > > Of course, I suppose that's kind of my opinion. I'm sure some will think > that the "historical trend" of release instability is simply due to a lack > of > effort (obviously Cassandra developers don't give a shit about users, that > must the simplest explanation). >
Re: Proposal - 3.5.1
I'm not even sure it's reasonable to expect from *any* software, and even less so for an open-source project based on volunteering. Not saying it wouldn't be amazing, it would, I just don't believe it's realistic. Postgres does a pretty good job of this. This sort of thinking is a self fulfilling prophecy imo. Clearly, we won’t get to this point right away, but it should definitely be a goal. On September 16, 2016 at 9:04:03 AM, Sylvain Lebresne (sylv...@datastax.com) wrote: On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad wrote: > > This is a different mentality from having a "features" branch, where it's > implied that at times it's acceptable that it not be stable. I absolutely never implied that, though I willingly admit my choice of branch names may be to blame. I 100% agree that no releases should be done without a green test board moving forward and if something was implicit in my 'feature' branch proposal, it was that. Where we might not be in the same page is that I just don't believe it's reasonable to expect the project will get any time soon in a state where even a green test board release (with new features) meets the "can be confidently put into production". I'm not even sure it's reasonable to expect from *any* software, and even less so for an open-source project based on volunteering. Not saying it wouldn't be amazing, it would, I just don't believe it's realistic. In a way, the reason why I think tick-tock doesn't work is *exactly* because it's based on that unrealistic assumption. Of course, I suppose that's kind of my opinion. I'm sure some will think that the "historical trend" of release instability is simply due to a lack of effort (obviously Cassandra developers don't give a shit about users, that must the simplest explanation).
Re: Proposal - 3.5.1
On Fri, Sep 16, 2016 at 11:36 AM, Jonathan Haddad wrote: > What I was trying to suggest is that the *goal* of trunk should always be > releasable, and the alpha releases would be the means of testing that. If > the goal is to always be releasable, we move towards achieving that goal by > improving modularity, test coverage and test granularity. > > Yes, it's very difficult to prove a piece of software is completely free of > bugs and I wouldn't expect NASA to put Cassandra on the space shuttle. > That said, by prioritizing stability in the software development process up > front, the cost of maintaining older branches over time will decrease and > the velocity of the project will increase - which was the original goal of > Tick Tock. > And we *did* make substantial progress on this. Not nearly as quickly as I originally hoped, but our CI is worlds cleaner and more useful than it was this time last year. -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
Re: Proposal - 3.5.1
Yep - the progress that's been made on trunk recently has been excellent and should continue. The spirit of tick tock - stable trunk - should not change, just that the release cycle did not support what humans are comfortable with maintaining or deploying. On Fri, Sep 16, 2016 at 10:08 AM Jonathan Ellis wrote: > On Fri, Sep 16, 2016 at 11:36 AM, Jonathan Haddad > wrote: > > > What I was trying to suggest is that the *goal* of trunk should always be > > releasable, and the alpha releases would be the means of testing that. > If > > the goal is to always be releasable, we move towards achieving that goal > by > > improving modularity, test coverage and test granularity. > > > > Yes, it's very difficult to prove a piece of software is completely free > of > > bugs and I wouldn't expect NASA to put Cassandra on the space shuttle. > > That said, by prioritizing stability in the software development process > up > > front, the cost of maintaining older branches over time will decrease and > > the velocity of the project will increase - which was the original goal > of > > Tick Tock. > > > > And we *did* make substantial progress on this. Not nearly as quickly as I > originally hoped, but our CI is worlds cleaner and more useful than it was > this time last year. > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced >
Re: Proposal - 3.5.1
On Fri, Sep 16, 2016 at 6:59 PM, Blake Eggleston wrote: > Clearly, we won’t get to this point right away, but it should definitely > be a goal. > I'm not entirely clear on why anyone would read in what I'm saying that it shouldn't be a goal. I'm a huge proponent of this and of putting emphasis on quality in general, and because it's Friday night and I'm tired, I'm gonna add that I think I have a bigger track record of actually acting on improving quality for Cassandra than anyone else that is putting word in my mouth. Mainly, I'm suggesting that we don't have to tie the existence of a clearly labeled stable branch (useful to user, especially newcomers) to future improvement in the "releasability" of trunk in our design of a new release cycle. If we do so, but releasability don't improve as quickly as we'd hope, we penalize users in the end. Adopting a release cycle that ensure said clearly labeled stable branch does exist no matter the rate of improvement to the level of "trunk" releasibility is feels safer, and doesn't preclude any effort in improving said releasibilty, nor re-evaluating this in 1-2 year to move to release stable releases from trunk directly if we have proven we're there. > > On September 16, 2016 at 9:04:03 AM, Sylvain Lebresne ( > sylv...@datastax.com) wrote: > > On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad > wrote: > > > > > This is a different mentality from having a "features" branch, where it's > > implied that at times it's acceptable that it not be stable. > > > I absolutely never implied that, though I willingly admit my choice of > branch > names may be to blame. I 100% agree that no releases should be done > without a green test board moving forward and if something was implicit > in my 'feature' branch proposal, it was that. > > Where we might not be in the same page is that I just don't believe it's > reasonable to expect the project will get any time soon in a state where > even a green test board release (with new features) meets the "can be > confidently put into production". I'm not even sure it's reasonable to > expect from *any* software, and even less so for an open-source > project based on volunteering. Not saying it wouldn't be amazing, it > would, I just don't believe it's realistic. In a way, the reason why I > think > tick-tock doesn't work is *exactly* because it's based on that unrealistic > assumption. > > Of course, I suppose that's kind of my opinion. I'm sure some will think > that the "historical trend" of release instability is simply due to a lack > of > effort (obviously Cassandra developers don't give a shit about users, that > must the simplest explanation). >
Re: [VOTE] Release Apache Cassandra 3.0.9
non-binding +1 Here's the testing summary on the 3.0.9-tentative tag: http://12.am/tmp/3.0.9-tests.png -- Michael On 09/15/2016 01:57 PM, Jake Luciani wrote: > I propose the following artifacts for release as 3.0.9. > > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.9-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1124/org/apache/cassandra/apache-cassandra/3.0.9/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-1124/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~jake > > The vote will be open for 72 hours (longer if needed). > > [1]: https://goo.gl/JKkE05 (CHANGES.txt) > [2]: https://goo.gl/Hi8X71 (NEWS.txt) >
Re: Proposal - 3.5.1
If you all have never seen the movie "grandma's boy" I suggest it. https://www.youtube.com/watch?v=uJLQ5DHmw-U There is one funny seen where the product/project person says something like, "The game is ready. We have fixed ALL THE BUGS". The people who made the movie probably think the coders doing dance dance revolution is funny. To me the funniest part of the movie is the summary statement that "all the bugs are fixed". I agree with Sylvain, that cutting branches really has nothing to do with "quality". Quality like "production ready" is hard to define. I am phrasing this next part as questions to encourage deep thought not to be a jerk. Someone jokingly said said 3.0 was the "break everything" release. What if 4.0 was the "fix everything" release? What would that mean? What would we need? No new features for 6 months? A vast network of amazon machines to test things? Jepsen ++? 24 hour integration tests that run CAS operations across a multi-node mixed version cluster while we chaos monkey nodes? Could we keep busy for 6 months just looking at the code and fix all the bugs for Mr. Cheezle? Could we fix ALL THE BUGS and then from that day it is just feature, feature, feature? We sit there and join and unjoin nodes for 2 days while running stress and at the end use the map reduce export and prove that not a single datum was lost? On Fri, Sep 16, 2016 at 2:42 PM, Sylvain Lebresne wrote: > On Fri, Sep 16, 2016 at 6:59 PM, Blake Eggleston > wrote: > > > Clearly, we won’t get to this point right away, but it should definitely > > be a goal. > > > > I'm not entirely clear on why anyone would read in what I'm saying that it > shouldn't be a goal. I'm a huge proponent of this and of putting emphasis > on quality in general, and because it's Friday night and I'm tired, I'm > gonna add that I think I have a bigger track record of actually acting on > improving quality for Cassandra than anyone else that is putting word in my > mouth. > > Mainly, I'm suggesting that we don't have to tie the existence of a clearly > labeled stable branch (useful to user, especially newcomers) to future > improvement in the "releasability" of trunk in our design of a new release > cycle. If we do so, but releasability don't improve as quickly as we'd > hope, we penalize users in the end. Adopting a release cycle that ensure > said clearly labeled stable branch does exist no matter the rate of > improvement to the level of "trunk" releasibility is feels safer, and > doesn't preclude any effort in improving said releasibilty, nor > re-evaluating this in 1-2 year to move to release stable releases from > trunk directly if we have proven we're there. > > > > > > > On September 16, 2016 at 9:04:03 AM, Sylvain Lebresne ( > > sylv...@datastax.com) wrote: > > > > On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad > > wrote: > > > > > > > > This is a different mentality from having a "features" branch, where > it's > > > implied that at times it's acceptable that it not be stable. > > > > > > I absolutely never implied that, though I willingly admit my choice of > > branch > > names may be to blame. I 100% agree that no releases should be done > > without a green test board moving forward and if something was implicit > > in my 'feature' branch proposal, it was that. > > > > Where we might not be in the same page is that I just don't believe it's > > reasonable to expect the project will get any time soon in a state where > > even a green test board release (with new features) meets the "can be > > confidently put into production". I'm not even sure it's reasonable to > > expect from *any* software, and even less so for an open-source > > project based on volunteering. Not saying it wouldn't be amazing, it > > would, I just don't believe it's realistic. In a way, the reason why I > > think > > tick-tock doesn't work is *exactly* because it's based on that > unrealistic > > assumption. > > > > Of course, I suppose that's kind of my opinion. I'm sure some will think > > that the "historical trend" of release instability is simply due to a > lack > > of > > effort (obviously Cassandra developers don't give a shit about users, > that > > must the simplest explanation). > > >
Re: [VOTE] Release Apache Cassandra 3.0.9
+1 On 09/15/2016 02:57 PM, Jake Luciani wrote: I propose the following artifacts for release as 3.0.9. sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.9-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1124/org/apache/cassandra/apache-cassandra/3.0.9/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1124/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 72 hours (longer if needed). [1]: https://goo.gl/JKkE05 (CHANGES.txt) [2]: https://goo.gl/Hi8X71 (NEWS.txt)
