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 it and move on.
On Fri, Apr 3, 2020 at 2:48 AM Joshua McKenzie <jmcken...@apache.org> wrote: > 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 protocol change there's a clear forcing > function to get it into 4.0 since a) it's minor and b) the time horizon for > the next major is very uncertain. > > If we go a route that doesn't require a protocol change it can just go into > the next patch release after 4.0 right? Is there an urgency to get it into > 4.0.0 I'm missing in this scenario? > > > On Thu, Apr 2, 2020 at 5:25 PM sankalp kohli <kohlisank...@gmail.com> > wrote: > > > 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 features can be merged then based on this justification!! > > > > > > Considering this is a small feature, I wont -1 on it. I will disagree > and > > commit. > > > > > > > > On Thu, Apr 2, 2020 at 1:04 PM Jon Haddad <j...@jonhaddad.com> wrote: > > > > > 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 > > > table. > > > > > > Quite a bit of Chris's patch also fixes our broken server side CQL > > > generation, something that affects correctness in our snapshots. So > > either > > > way most of the code needs to go in before we release 4.0. Adding a > > single > > > file that creates a new virtual table is so trivial I'm having a hard > > time > > > understanding the opposition. > > > > > > On Thu, Apr 2, 2020 at 12:56 PM Nate McCall <zznat...@gmail.com> > wrote: > > > > > > > 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 required to review/merge/update > > these > > > > patches and we are trying to release > > > > - the change is unintrusive > > > > - this is a change to the protocol > > > > > > > > Not having this doesnt effect me for $dayJob, but I want to reiterate > > > that > > > > it's a silly thing to leave to clients. Given we've previously scoped > > it > > > to > > > > 4.0, im still +1 on adding it. > > > > > > > > It's ok to have differing opinions. I'd like to see us disagree and > > > commit > > > > to a course of action either way as opposed to just letting it sit > more > > > > because we can't sort it out. > > > > > > > > > >
