Honest question: are you *ever* positive Ed? Maybe give it a shot once in a while. It will be good for your mental health.
Sent from my iPhone > On Nov 19, 2016, at 11: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 >> <javascript:_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.
