Supportive of this as well.
I see testability of trunk against JDK17 as more important than continuous
preservation of support for scripted UDFs *during* that development.
Will be tempted to cherry-pick this and begin kicking the tires as soon as it’s
ready. 👍
- Scott
> On Feb 5, 2023, at 6:
> To my understanding this wasn't the original desire and consensus with
> JDK17, folk requested that it be introduced complete, though I cannot
> actually find the reference to that. I was about to raise a thread asking
> for us to instead take an incremental approach, to help us move faster and
Love the write up Henrik :-8
> On Fri, Feb 3, 2023, at 9:20 AM, Henrik Ingo wrote:
>
> …
> 1) I assume JDK17 support is invasive, so that would suggest a feature
> branch. However, the next question is, is there any risk involved in this
> work (like Falcon for MySQL). Hypothetically it could be
I think Henrik has a lot of good points. However, I want to point out that
JDK upgrades are non-optional over the fullness of time, so it might be
worth carving out a specific process for that work. In a similar vein,
security patches also Just Need to Merge™, so I'm a little hesitant when I
see th
I am all in for incremental changes which are fine to get into release.
In the case of JDK 17 I know dependencies which need to be updated for Java
17 but they still work with Java8 and 11 so it is fine to update them
before the switch.
So while some blockers are removed, I do the updates in parall
> *Suddenly, you get to be doubly managerial for making _two_ inconsequential
> decisions - the wrong one _and_ the right one.*
Something to aspire to. :)
On Fri, Feb 3, 2023, at 9:20 AM, Henrik Ingo wrote:
> I've been an unusually active debater recently, so it might be appropriate to
> start
I've been an unusually active debater recently, so it might be appropriate
to start with a reminder/disclaimer that I'm not actually a Cassandra
contributor in any way(*), but I choose to share some thoughts where I feel
that sharing experiences from other open source database projects can be of
us
Yes, I think that some refactors can also be directly merged if they have a
value for the end user on their own. Changes providing cleaner, better
documented and less tightly coupled code can have that value, even if they
aren't a new feature. Things like new APIs without an implementation
probably
The deeply coupled nature of some areas of our codebase does have some
constraints it imposes on us here to your point. Without sensible internal APIs
a lot of this type of work expands into two phases, one to refactor out said
APIs and the other to introduce new functionality.
It probably dep
I'm not sure a CEP is necessarily a big, complex piece of work that needs
to be split into multiple tickets. There could be single-ticket CEPs that
don't need multiple tickets, and still need the bureaucracy of a CEP due to
the impact of the change. However that probably isn't the common case.
Als
This is quite timely as we're just gearing up to begin pushing the work we've
been doing on CEP-21 into the public domain.
This CEP is a slightly different from others that have gone before in that it
touches almost every area of the system. This presents a few implementation
challenges, most
Anything we either a) have to do (JDK support) or b) have all agreed up front
we think we should do (CEP). I.e. things with a lower risk of being left dead
in the codebase partially implemented.
I don't think it's a coincidence we've set up other processes to help de-risk
and streamline the con
On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie wrote:
>
> My current thinking: I'd like to propose we all agree to move to merge work
> into trunk incrementally if it's either:
> 1) New JDK support
> 2) An approved CEP
So basically everything? I'm not sure what large complex bodies of
work would
The topic of how we handle merging large complex bodies of work came up
recently with the CEP-15 merge and JDK17, and we've faced this question in the
past as well (CASSANDRA-8099 comes to mind).
The times we've done large bodies of work separately from trunk and then merged
them in have their
14 matches
Mail list logo
