+1 let's keep moving forward. Dinesh
> On Apr 9, 2020, at 4:07 PM, Nate McCall <zznat...@gmail.com> wrote: > > Ok cool. It sounds like we are moving this towards a consensus? (at least > agreeing to disagree and moving forward). > > I very much the different inputs on this thread - thanks for a largely > healthy discussion folks. > > On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink <clohfin...@gmail.com> wrote: > >> I'd be in favor of going with the newer DESCRIBE option. The original patch >> was mostly focused on just getting the CQL correct and used virtual tables >> because its what the initial feedback was to do. Robert added a lot of >> functionality on top of what was there which is what people were starting >> to ask for. I am in favor of just going off of his patch and moving >> forward. I initially heard post 4.0 so I know I haven't been focused on it >> but if theres desire to put it in 4.0 I am +1 on it and would like to see >> just going off of the Robert's latest patch. >> >> Chris >> >> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <benjamin.le...@datastax.com >>> >> wrote: >> >>> Thanks for your answer Alex. >>> >>> Some of the things we >>>> have explicitly (as a community) agreed to commit are still in >> progress, >>>> including several client protocol changes. And, to my understanding, if >>>> those are committed, it'll be what community has agreed upon. >>>> >>> >>> If the understanding of the community was that this patch was expected to >>> go in 4.0 then it makes sense to commit it there. >>> >>> >>>> If the discussion is about whether or not to include _some_ version of >>> the >>>> patch, I think including it makes sense, especially given the patch was >>>> there for a while and was not committed for non-technical reasons. If >>> we're >>>> trying to decide _which_ patch to commit, I'd personally focus on the >>>> original patch (to foster recognition), get it reviewed, and pick any >>>> changes that make it better from the follow-up one (to foster >>>> collaboration). >>>> >>> >>> I am fine going through both patches and figuring out a way to merge them >>> into one if Jon or somebody else is willing to review the output of that >>> merge >>> >>> >>> >>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith < >>> bened...@apache.org> >>> wrote: >>> >>>> +1 all of this >>>> >>>> On 09/04/2020, 10:23, "Oleksandr Petrov" <oleksandr.pet...@gmail.com> >>>> wrote: >>>> >>>>> My understanding is that a majority of people ended up in favor >> of >>>> a DESCRIBE approach. Robert made a patch for that approach >> (according >>>> to >>>> his comment it was discussed with Chris beforehand). >>>> >>>> This sounds like just a switch of API (in other words, you use the >>> same >>>> string generation, but return it via different means). From the >>>> (little) >>>> time I've spent looking at the patch, I remember that there wasn't >>> much >>>> common code between the two (sorry if I'm remembering it wrong). >>>> >>>> If the discussion is about whether or not to include _some_ version >>> of >>>> the >>>> patch, I think including it makes sense, especially given the patch >>> was >>>> there for a while and was not committed for non-technical reasons. >> If >>>> we're >>>> trying to decide _which_ patch to commit, I'd personally focus on >> the >>>> original patch (to foster recognition), get it reviewed, and pick >> any >>>> changes that make it better from the follow-up one (to foster >>>> collaboration). >>>> >>>>> Where do we draw the line? >>>> >>>> I would discuss changes on the case-by-case basis. Some of the >> things >>>> we >>>> have explicitly (as a community) agreed to commit are still in >>>> progress, >>>> including several client protocol changes. And, to my >> understanding, >>> if >>>> those are committed, it'll be what community has agreed upon. All >>>> further >>>> changes that weren't discussed yet - we can talk over. If it's >>>> something as >>>> trivial as server-side describe that doesn't risk stability but >> adds >>> a >>>> lot >>>> of value, it may make sense to include. But I woudln't attempt to >>> come >>>> up >>>> with a general rule for what we may or may not consider for now. >>>> >>>> >>>> On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer < >>>> benjamin.le...@datastax.com> >>>> wrote: >>>> >>>>> We have already discussed it for several days and I believe that >>> all >>>> the >>>>> points have been brought to the table. >>>>> >>>>> I took the time to read CASSANDRA-14825 this morning to >> understand >>>> the full >>>>> story. >>>>> All the discussion has been about using Virtual Tables versus >> using >>>>> DESCRIBE. >>>>> My understanding is that a majority of people ended up in favor >> of >>> a >>>>> DESCRIBE approach (skipping the details on purpose here). >>>>> Robert made a patch for that approach (according to his comment >> it >>>> was >>>>> discussed with Chris beforehand). >>>>> >>>>> The question here is should: we agree to put it in 4.0 even if >> the >>>> version >>>>> is frozen for improvements. >>>>> >>>>> My main reason against it is that if we broke the freeze for >> every >>>> ticket >>>>> we believe might be useful we will end up delaying 4.0 a lot. >>>>> Are there not other tickets that are more valuable than >>>> CASSANDRA-14825, >>>>> that are not included in 4.0? >>>>> Where do we draw the line? >>>>> >>>>> I believe that if we were able to answer that question it would >>>> suddenly >>>>> become much easier to agree on which tickets we put in 4.0. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith < >>>> bened...@apache.org >>>>>> >>>>> wrote: >>>>> >>>>>> There it is. I knew it would show up eventually. >>>>>> >>>>>> On 04/04/2020, 06:26, "bened...@apache.org" < >>>> pub...@belliottsmith.com> >>>>>> wrote: >>>>>> >>>>>>> scope creep. >>>>>> >>>>>> I think it is unfair to label this scope creep; it would >> have >>>> to be >>>>>> newly considered for 4.0 for it to fall under that umbrella. >>>>>> >>>>>> I don't personally mind if it lands, but this was discussed >>> at >>>> length >>>>>> on multiple occasions over the past year, and only stalled >>> because >>>> of a >>>>>> combination of lack of etiquette, and a lack of leadership from >>>> e.g. PMC >>>>> in >>>>>> resolving various political questions over the course of >> events. >>>>>> >>>>>> I also struggle to see how this would invalidate testing in >>> any >>>>>> significant way? It doesn't modify any existing behaviour. >>>>>> >>>>>> ________________________________ >>>>>> From: Joshua McKenzie <jmcken...@apache.org> >>>>>> Sent: 01 April 2020 19:24 >>>>>> To: dev@cassandra.apache.org <dev@cassandra.apache.org> >>>>>> Subject: Re: server side describe >>>>>> >>>>>> This looks like a feature that'd potentially invalidate >> some >>>> testing >>>>>> that's >>>>>> been done and we've been feature frozen for over a year >> and a >>>> half. >>>>>> Also: >>>>>> scope creep. >>>>>> >>>>>> My PoV is we hold off. If we get into a cadence of more >>>> frequent >>>>>> releases >>>>>> we'll have it soon enough. >>>>>> >>>>>> On Wed, Apr 1, 2020 at 3:03 PM <e.dimitr...@gmail.com> >>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> Normally I ping the person on the ticket or in Slack to >> ask >>>> him/her >>>>>> for >>>>>>> status update and whether I can help. Then probably >> he/she >>>> gives >>>>> me a >>>>>>> direction. >>>>>>> If I can’t find the person anymore, I just use my best >>>> judgement >>>>> and >>>>>>> coordinate with people who might know better than me. >>>>>>> For now this strategy worked for me personally. >>>>>>> Hope this helps >>>>>>> Ekaterina >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On 1 Apr 2020, at 14:27, Jon Haddad <j...@jonhaddad.com >>> >>>> wrote: >>>>>>>> >>>>>>>> Hey folks, >>>>>>>> >>>>>>>> I was looking through our open JIRAs and realized we >>> hadn't >>>>> merged >>>>>> in >>>>>>>> server side describe calls yet. The ticket died off a >>>> ways ago, >>>>>> and I >>>>>>>> pinged Chris about it yesterday. He's got a lot of his >>>> plate and >>>>>> won't >>>>>>> be >>>>>>>> able to work on it anytime soon. I still think we >> should >>>> include >>>>>> this in >>>>>>>> 4.0. >>>>>>>> >>>>>>>> From a technical standpoint, It doesn't say much on the >>>> ticket >>>>>> after >>>>>>> Robert >>>>>>>> tossed an alternative patch out there. I don't mind >>>> reviewing >>>>> and >>>>>>> merging >>>>>>>> either of them, it sounded like both are pretty close >> to >>>> done and >>>>>> I think >>>>>>>> from the perspective of updating drivers for 4.0 this >>> will >>>> save >>>>>> quite a >>>>>>> bit >>>>>>>> of time since driver maintainers won't have to add new >>> CQL >>>>>> generation for >>>>>>>> the various new options that have recently appeared. >>>>>>>> >>>>>>>> Questions: >>>>>>>> >>>>>>>> * Does anyone have an objection to getting this into >> 4.0? >>>> The >>>>>> patches >>>>>>>> aren't too huge, I think they're low risk, and also >>> fairly >>>> high >>>>>> reward. >>>>>>>> * I don't have an opinion (yet) on Robert's patch vs >>>> Chris's, >>>>> with >>>>>> regard >>>>>>>> to which is preferable. >>>>>>>> * Since soon after Robert put up his PR he hasn't been >>>> around, at >>>>>> least >>>>>>> as >>>>>>>> far as I've seen. How have we dealt with abandoned >>> patches >>>>>> before? If >>>>>>>> we're going to add this in the patch will need some >>>> cleanup. Is >>>>> it >>>>>>>> reasonable to continue someone else's work when they've >>>>>> disappeared? >>>>>>>> >>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> alex p >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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
