> 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
