ds
>>>>>>> a
>>>>>>>> lot
>>>>>>>> of value, it may make sense to include. But I woudln't attempt
>> to
>>>>>>> come
>>>>>>>> up
>>>>>>>> with a ge
; all
> > > >>>> the
> > > >>>>> points have been brought to the table.
> > > >>>>>
> > > >>>>> I took the time to read CASSANDRA-14825 this morning to
> > > >> understand
> > > >>>> t
o
> > >> understand
> > >>>> the full
> > >>>>> story.
> > >>>>> All the discussion has been about using Virtual Tables versus
> > >> using
> > >>>>> DESCRIBE.
> > >>>>> My
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 he
gt; 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
n which tickets we put in 4.0.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
> > > bened...@apache.org
> > >
20, 06:26, "bened...@apache.org" <
> > pub...@belliottsmith.com>
> > > > wrote:
> > > >
> > > > > scope creep.
> > > >
> > > > I think it is unfair to label this scope creep; it would hav
f 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
> > > resolvin
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.
> >
> >
> > I also struggle to see how this would invalidate testing in any
> > significant way? It doesn't modify any existing behaviour.
> >
> >
> > From: Joshua McKenzie
> > Sent: 01 April 2020 19:24
> &
n any
> significant way? It doesn't modify any existing behaviour.
>
>
> From: Joshua McKenzie
> Sent: 01 April 2020 19:24
> To: dev@cassandra.apache.org
> Subject: Re: server side describe
>
> This looks like a feature
le to see how this would invalidate testing in any significant
way? It doesn't modify any existing behaviour.
From: Joshua McKenzie
Sent: 01 April 2020 19:24
To: dev@cassandra.apache.org
Subject: Re: server side describe
Th
From: Joshua McKenzie
Sent: 01 April 2020 19:24
To: 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
>
> Someone once said:
In my opinion, sniping like this doesn't help us move the conversation
forward. Please reach out to other contributors who's behavior you have
concerns with separately.
On Fri, Apr 3, 2020 at 12:23 PM Joshua McKenzie
wrote:
> This isn't a hill to die on or something to bi
This isn't a hill to die on or something to binding -1 for me
personally. In a vacuum this merge is totally fine. The problem for me
comes in if a merge like this is one of 10, or 50, or 100 things that
are innocuous in isolation. IMO as long as we make sure this is the
only cut we do to ourselves
Someone once said:
"I heard the expression recently that “there are ten ways to do this, and
eight of them will work.” I think that applies to most of the code we
write. We don't need to spend a lot of time discussing which of the eight
is best; let’s trust the judgement of the original author a
It seems to me that we need to get better at making decisions for things
like that.
If we keep on arguing for small things, it will simply be time consuming
and painfull for everybody.
In this case, the situation seems simple.
Part of the group do not agree with the proposal. We just have to accept
One thing probably worth thinking about: we're a mostly irascible lot to
begin with and there's a global pandemic and Human Race Lockdown. I don't
know about the rest of you but I'm starting from a pretty not-chill place
these days; trying to be mindful of that.
So for this: if we require a protoc
Whether a feature is fully done and whether it validates or invalidate
testing is not the point here. The point is that it is a feature and
violates feature freeze. If someone brings in a feature which is almost
done and does not invalidate testing then will we merge all of them to 4.0?
Lot of feat
Chris's original patch used a virtual table which didn't even require a
protocol change. To me, the difference between having a CQL describe vs a
virtual table is unimportant, since it's only drivers that need to care
about it. I'm completely fine with the simpler implementation of a virtual
tabl
So summarizing the salient points here:
- client authors have worked around this mostly, but this would avoid some
duplication of effort for new features
- this issues was tagged last year as being pertinent to 4.0 in several
threads about what was in scope
- there is some development efforts requi
Yeah, I feel like it’s a bad example to use to highlight 4.0 scope creep (which
is less of a thing than some fear).
The work there is already done, and it’s extremely unintrusive. There is no
reason whatsoever to block 4.0 on it, but no reason not to commit - now, in a
beta, in the first RC, or
Sorry if this is a repeat message; I messed up my mail client settings (I don't
see it today, but it might just be stuck in an unmonitored moderator queue):
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, surely?
I
+1 for shipping it after 4.0
On Thu, Apr 2, 2020 at 12:39 AM Jon Haddad wrote:
> Most of the work to provide this feature is already done. We need to
> generate server side CQL for snapshots already. All we need to do is
> expose it via either a "DESCRIBE" CQL command, or I'm equally happy t
Most of the work to provide this feature is already done. We need to
generate server side CQL for snapshots already. All we need to do is
expose it via either a "DESCRIBE" CQL command, or I'm equally happy to see
it land in a virtual table.
On Wed, Apr 1, 2020 at 2:45 PM sankalp kohli wrote:
>
+1 on holding off and focus on shipping 4.0
On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie
wrote:
> 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. I
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 w
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 str
That's totally fair - but this brings us back to needing a discussion and
plan on prioritization for what 4.next looks like.
On Thu, Apr 2, 2020 at 7:41 AM Brandon Williams wrote:
> I want to start by saying I don't disagree with you on this issue.
>
> But, I do want to highlight that feature cr
+1. My preference is to have `DESCRIBE` CQL statement.
Dinesh
> On Apr 1, 2020, at 11:33 AM, Nate McCall wrote:
>
> I think part of being a modern database is not relying on drivers/clients
> to idiomatically rebuild the schema.
>
> Thanks for bringing it up, Jon - huge +1 on merging (some for
I want to start by saying I don't disagree with you on this issue.
But, I do want to highlight that feature creep is real, and hurting
our impending release.
On Wed, Apr 1, 2020 at 1:33 PM Nate McCall wrote:
>
> I think part of being a modern database is not relying on drivers/clients
> to idio
I think we should get serious about the so-called freeze.
On Wed, Apr 1, 2020 at 1:27 PM Jon Haddad 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 yeste
I think part of being a modern database is not relying on drivers/clients
to idiomatically rebuild the schema.
Thanks for bringing it up, Jon - huge +1 on merging (some form) of this.
On Thu, Apr 2, 2020 at 7:27 AM Jon Haddad wrote:
> Hey folks,
>
> I was looking through our open JIRAs and real
33 matches
Mail list logo
