This was not for the Dev list :)
> On Nov 20, 2016, at 09:06, Sankalp Kohli <kohlisank...@gmail.com> wrote: > > I have asked him to calm down as these things are never constructive for the > community. Making personal comments put him in bad light more than anytime > else. > I will speak with him in person when we are in office. > > Thanks for keeping an eye on these things for us. I will setup another > meeting with you to talk about Cassandra strategies. > >> On Nov 20, 2016, at 06:50, Jason Brown <jasedbr...@gmail.com> wrote: >> >> Hey all, >> >> One of the goals on my team, when working on large patches, is to get >> community feedback on these initiatives before throwing them into prod. >> This gets us a wider net of feedback (see Sylvain's continuing excellent >> rounds of feedback to my work on CASSANDRA-8457), as well as making sure we >> don't go too far off the deep end in terms of straying from the community >> version. The latter point is crucial because if we make too many >> incompatible changes to, for example, the internode messaging protocol or >> the CQL protocol or the sstable file format, and deploy that, it may be >> very difficult, if not impossible, to rectify with future, in-development >> versions of cassandra. >> >> We fully intend to "engineer and test the snot out of" the changes we are >> working on as the whole point of us working on them is so we *can* run them >> in production, at our scale. We aren't expecting others in the community to >> dog food it for us. There will be a delay between committing something >> upstream, and us backporting it to a current version we run in production >> and actually deploying it. However, you can be sure that any bugs we find >> will be fixed ASAP; we have many users counting on it. >> >> Thanks for listening, >> >> -Jason >> >> >> On Sat, Nov 19, 2016 at 11:04 AM, Blake Eggleston <beggles...@apple.com> >> wrote: >> >>> I think Ed's just using gossip 2.0 as a hypothetical example. His point is >>> that we should only commit things when we have a high degree of confidence >>> that they work correctly, not with the expectation that they don't. >>> >>> >>> On November 19, 2016 at 10:52:38 AM, Michael Kjellman ( >>> mkjell...@internalcircle.com) wrote: >>> >>> Jason has asked for review and feedback many times. Maybe be constructive >>> and review his code instead of just complaining (once again)? >>> >>> Sent from my iPhone >>> >>>> On Nov 19, 2016, at 1:49 PM, Edward Capriolo <edlinuxg...@gmail.com> >>> wrote: >>>> >>>> I would say start with a mindset like 'people will run this in >>> production' >>>> not like 'why would you expect this to work'. >>>> >>>> Now how does this logic effect feature develement? Maybe use gossip 2.0 >>> as >>>> an example. >>>> >>>> I will play my given debby downer role. I could imagine 1 or 2 dtests and >>>> the logic of 'dont expect it to work' unleash 4.0 onto hords of nubes >>> with >>>> twitter announce of the release let bugs trickle in. >>>> >>>> One could also do something comprehensive like test on clusters of 2 to >>>> 1000 nodes. Test with jepsen to see what happens during partitions, >>> inject >>>> things like jvm pauses and account for behaivor. Log convergence times >>>> after given events. >>>> >>>> Take a stand and say look "we engineered and beat the crap out of this >>>> feature. I deployed this release feature at my company and eat my >>> dogfood. >>>> You are not my crash test dummy." >>>> >>>> >>>>> On Saturday, November 19, 2016, Jeff Jirsa <jji...@gmail.com> wrote: >>>>> >>>>> Any proposal to solve the problem you describe? >>>>> >>>>> -- >>>>> Jeff Jirsa >>>>> >>>>> >>>>>> On Nov 19, 2016, at 8:50 AM, Edward Capriolo <edlinuxg...@gmail.com >>>>> <;>> wrote: >>>>>> >>>>>> This is especially relevant if people wish to focus on removing things. >>>>>> >>>>>> For example, gossip 2.0 sounds great, but seems geared toward huge >>>>> clusters >>>>>> which is not likely a majority of users. For those with a 20 node >>> cluster >>>>>> are the indirect benefits woth it? >>>>>> >>>>>> Also there seems to be a first push to remove things like compact >>> storage >>>>>> or thrift. Fine great. But what is the realistic update path for >>> someone. >>>>>> If the big players are running 2.1 and maintaining backports, the >>> average >>>>>> shop without a dedicated team is going to be stuck saying (great >>> features >>>>>> in 4.0 that improve performance, i would probably switch but its not >>>>> stable >>>>>> and we have that one compact storage cf and who knows what is going to >>>>>> happen performance wise when) >>>>>> >>>>>> We really need to lose this realease wont be stable for 6 minor >>> versions >>>>>> concept. >>>>>> >>>>>> On Saturday, November 19, 2016, Edward Capriolo <edlinuxg...@gmail.com >>>>> <;>> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Friday, November 18, 2016, Jeff Jirsa <jeff.ji...@crowdstrike.com >>>>> <;> >>>>>>> <_e(%7B%7D,'cvml','jeff.ji...@crowdstrike.com <;>');>> >>>>> wrote: >>>>>>> >>>>>>>> We should assume that we’re ditching tick/tock. I’ll post a thread on >>>>>>>> 4.0-and-beyond here in a few minutes. >>>>>>>> >>>>>>>> The advantage of a prod release every 6 months is fewer incentive to >>>>> push >>>>>>>> unfinished work into a release. >>>>>>>> The disadvantage of a prod release every 6 months is then we either >>>>> have >>>>>>>> a very short lifespan per-release, or we have to maintain lots of >>>>> active >>>>>>>> releases. >>>>>>>> >>>>>>>> 2.1 has been out for over 2 years, and a lot of people (including us) >>>>> are >>>>>>>> running it in prod – if we have a release every 6 months, that means >>>>> we’d >>>>>>>> be supporting 4+ releases at a time, just to keep parity with what we >>>>> have >>>>>>>> now? Maybe that’s ok, if we’re very selective about ‘support’ for 2+ >>>>> year >>>>>>>> old branches. >>>>>>>> >>>>>>>> >>>>>>>> On 11/18/16, 3:10 PM, "beggles...@apple.com <;> on behalf >>>>> of Blake >>>>>>>> Eggleston" <beggles...@apple.com <;>> wrote: >>>>>>>> >>>>>>>>>> While stability is important if we push back large "core" changes >>>>>>>> until later we're just setting ourselves up to face the same issues >>>>> later on >>>>>>>>> >>>>>>>>> In theory, yes. In practice, when incomplete features are earmarked >>>>> for >>>>>>>> a certain release, those features are often rushed out, and not >>> always >>>>>>>> fully baked. >>>>>>>>> >>>>>>>>> In any case, I don’t think it makes sense to spend too much time >>>>>>>> planning what goes into 4.0, and what goes into the next major >>> release >>>>> with >>>>>>>> so many release strategy related decisions still up in the air. Are >>> we >>>>>>>> going to ditch tick-tock? If so, what will it’s replacement look >>> like? >>>>>>>> Specifically, when will the next “production” release happen? Without >>>>>>>> knowing that, it's hard to say if something should go in 4.0, or 4.5, >>>>> or >>>>>>>> 5.0, or whatever. >>>>>>>>> >>>>>>>>> The reason I suggested a production release every 6 months is >>> because >>>>>>>> (in my mind) it’s frequent enough that people won’t be tempted to >>> rush >>>>>>>> features to hit a given release, but not so frequent that it’s not >>>>>>>> practical to support. It wouldn’t be the end of the world if some of >>>>> these >>>>>>>> tickets didn’t make it into 4.0, because 4.5 would fine. >>>>>>>>> >>>>>>>>> On November 18, 2016 at 1:57:21 PM, kurt Greaves ( >>>>> k...@instaclustr.com <;>) >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 18 November 2016 at 18:25, Jason Brown <jasedbr...@gmail.com >>>>> <;>> wrote: >>>>>>>>>> >>>>>>>>>> #11559 (enhanced node representation) - decided it's *not* >>> something >>>>> we >>>>>>>>>> need wrt #7544 storage port configurable per node, so we are >>> punting >>>>> on >>>>>>>>>> >>>>>>>>> >>>>>>>>> #12344 - Forward writes to replacement node with same address during >>>>>>>> replace >>>>>>>>> depends on #11559. To be honest I'd say #12344 is pretty important, >>>>>>>>> otherwise it makes it difficult to replace nodes without potentially >>>>>>>>> requiring client code/configuration changes. It would be nice to get >>>>>>>> #12344 >>>>>>>>> in for 4.0. It's marked as an improvement but I'd consider it a bug >>>>> and >>>>>>>>> thus think it could be included in a later minor release. >>>>>>>>> >>>>>>>>> Introducing all of these in a single release seems pretty risky. I >>>>> think >>>>>>>> it >>>>>>>>>> would be safer to spread these out over a few 4.x releases (as >>>>> they’re >>>>>>>>>> finished) and give them time to stabilize before including them in >>> an >>>>>>>> LTS >>>>>>>>>> release. The downside would be having to maintain backwards >>>>>>>> compatibility >>>>>>>>>> across the 4.x versions, but that seems preferable to delaying the >>>>>>>> release >>>>>>>>>> of 4.0 to include these, and having another big bang release. >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't think anyone expects 4.0.0 to be stable. It's a major >>> version >>>>>>>>> change with lots of new features; in the production world people >>> don't >>>>>>>>> normally move to a new major version until it has been out for quite >>>>> some >>>>>>>>> time and several minor releases have passed. Really, most people are >>>>> only >>>>>>>>> migrating to 3.0.x now. While stability is important if we push back >>>>>>>> large >>>>>>>>> "core" changes until later we're just setting ourselves up to face >>> the >>>>>>>> same >>>>>>>>> issues later on. There should be enough uptake on the early releases >>>>> of >>>>>>>> 4.0 >>>>>>>>> from new users to help test and get it to a production-ready state. >>>>>>>>> >>>>>>>>> >>>>>>>>> Kurt Greaves >>>>>>>>> k...@instaclustr.com <;> >>>>>>>> >>>>>>>> >>>>>>> I don't think anyone expects 4.0.0 to be stable >>>>>>> >>>>>>> Someone previously described 3.0 as the "break everything release". >>>>>>> >>>>>>> We know that many people are still 2.1 and 3.0. Cassandra will always >>> be >>>>>>> maintaining 3 or 4 active branches and have adoption issues if >>> releases >>>>> are >>>>>>> not stable and usable. >>>>>>> >>>>>>> Being that cassandra was 1.0 years ago I expect things to be stable. >>>>> Half >>>>>>> working features , or added this broke that are not appealing to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sorry this was sent from mobile. Will do less grammar and spell check >>>>> than >>>>>>> usual. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sorry this was sent from mobile. Will do less grammar and spell check >>>>> than >>>>>> usual. >>>>> >>>> >>>> >>>> -- >>>> Sorry this was sent from mobile. Will do less grammar and spell check >>> than >>>> usual. >>>
