I'll volunteer. Dinesh
> On Apr 16, 2020, at 12:47 AM, Benjamin Lerer <benjamin.le...@datastax.com> > wrote: > > Now that there is an agreement on having this patch on 4.0. I would like to > see it done as soon as possible. It would minimize the risks by giving us > more testing time. It will also give the driver developers a chance to use > it and provide feedback if they hit some issues. > > Robert rebased his patch yesterday and I started to review it. If somebody > else want to give another look to the patch, I am 100% for it. > > > > > On Wed, Apr 15, 2020 at 7:48 PM Jon Haddad <j...@jonhaddad.com> wrote: > >> I don't think we need to vote on this. A few folks have expressed (very >> justified) concern, but nobody has gone nuclear. >> >> I intended on cleaning up the patch and getting it ready for another >> review, but haven't had it in my brain and have been busy with other >> things. I don't claim exclusive rights to the clean up patch, if someone >> was motivated to do it I'd be 100% fine with it. :) >> >> >> >> >> On Wed, Apr 15, 2020 at 10:15 AM sankalp kohli <kohlisank...@gmail.com> >> wrote: >> >>> What are the next steps? Do we hold a vote as I see few initial emails >>> which dont seem to agree and have not replied based on future >> discussions. >>> >>> On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi <djo...@apache.org> wrote: >>> >>>> +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 >>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
