+1 to Maxim's idea
Like Stefan my assumption was that we would get some version of TCM + ACCORD in
5.0 but it wouldn't be ready for production use. My own testing and
conversations at Community over Code in Halifax confirmed this.
From this perspective as disappointing as TCM+ACCORD slipping is
Legal (Roman) helped clarify the situation for us, see comment on LEGAL-656.
We have the comments on CASSANDRA-18715 confirming ownership of both the
work being contributed and that belonging in the jvector library.
For our (downstream) users and their companies, these legal guarantees are
import
Thanks for your contribution 😀
Pawar, Amit 于2023年10月26日 周四下午11:41写道：
> [Public]
>
> Default behavior is not changed. Thank you, Josh for your appreciation.
> This is my first patch, and it means lot to me.
>
>
>
> Thanks again,
>
> Amit
>
>
>
> +1 to adding the feature, clear and easy configurab
[Public]
Default behavior is not changed. Thank you, Josh for your appreciation. This is
my first patch, and it means lot to me.
Thanks again,
Amit
+1 to adding the feature, clear and easy configurability, and if after a major
cycle we can say with confidence it's beating the status quo in the
I don’t want to take a view on how long stabilisation will take, as it’s guesswork. I hope it won’t be lengthy, but that I don’t think these guesses should affect the branch date.The question is only when we branch. The proposal I would endorse is that we branch as soon as TCM and Accord land. I th
Benedict, what is your expectation for stabilization time? And what is the
suggestion for the patches Benjamin mentioned, which are on their way to
land in trunk? (Or any other patch on its way to be merged)
On Thu, 26 Oct 2023 at 8:20, Benedict wrote:
> The time to stabilise is orthogonal to th
[Public]
Default behavior won’t be changed as per your feedback and a ‘direct’ mode can
be used to enable this feature. Thank you all again.
--
Amit
I think introducing the feature is a good idea.
I also think that it should _NOT_ be enabled by default for all the reasons
stated above.
Findin
The time to stabilise is orthogonal to the time we branch. Once we branch we stop accepting new features for the branch, and work to stabilise.My understanding is we will branch as soon as we have a viable alpha containing TCM and Accord. That means pretty soon after they land in the project, which
What Maxim proposes in the last paragraph would be definitely helpful. Not for
the project only but for a broader audience, companies etc., too.
Until this thread was started, my assumption was that "there will be 5.0 on
summit with TCM and Accord and it somehow just happens". More transparent
Josh,
Technically speaking, it will be the 3rd one, so yeah, the main goal
is to make the review process easier, my hands are trembling when I
look at the long technical discussion in that Jira issue :-) but I
also thought it might be a good idea to share the issue status with
the ML since the thr
Personally, I think frequent releases (2-3 per year) are better than
infrequent big releases. I can understand all the concerns from a
marketing perspective, as smaller major releases may not shine as
brightly as a single "game changer" release. However, smaller
releases, especially if they don't h
>
> Regarding the release of 5.1, I understood the proposal to be that we cut
> an actual alpha, thereby sealing the 5.1 release from new features. Only
> features merged before we cut the alpha would be permitted, and the alpha
> should be cut as soon as practicable. What exactly would we be waiti
>
> I am surprised this needs to be said, but - especially for long-running
> CEPs - you must involve yourself early, and certainly within some
> reasonable time of being notified the work is ready for broader input and
> review. In this case, more than six months ago.
It is unfortunately more co
13 matches
Mail list logo
