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