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 > > > > > > > > >
