Yeah, I positively dislike merge commits, both from a patch preparation
perspective and when trying to piece together a class’ history. It can actively
obfuscate the impact to the branch being looked at, as well as make it much
harder to skim the git log.
I’d vote to modify our merge strategy i
>
> I like a change originating from just one commit, and having tracking
> visible across the branches. This gives you immediate information about
> where and how the change was applied without having to go to the jira
> ticket (and relying on it being accurate)
I have the exact opposite experien
Does somebody else use the git workflow we do as of now in Apache
universe? Are not we quite unique? While I do share the same opinion
Mick has in his last response, I also see the disadvantage in having
the commit history polluted by merges. I am genuinely curious if there
is any other Apache proj
>
>
> > Merge commits aren’t that useful
> >
> I keep coming back to this. Arguably the only benefit they offer now is
> procedurally forcing us to not miss a bugfix on a branch, but given how
> much we amend many things presently anyway that dilutes that benefit.
>
Doesn't this come down to ho
Hi,
FYI I am planning to put together all we discussed under sstable
encryption thread into a kind-of CEP to distil everything said. I hope
I'll put it together in the foreseeable future before taking a longer
break till February. I am not sure if that is enough time to implement
it if we eventual
Sure :-)
I will make a separate section.
Le mar. 14 déc. 2021 à 17:30, C. Scott Andreas a
écrit :
> Thanks Benjamin!
>
> I see that the Roadmap doc on Confluence contains several features that
> are large in scope but do not have a published CEP or discussion on the
> mailing list.
>
> Because
Thanks Benjamin!I see that the Roadmap doc on Confluence contains several features that are large in scope but do not have a published CEP or discussion on the mailing list.Because users will treat the roadmap doc as indicative of the project’s direction and intent, can these items be moved to a s
Would 3.11 be considered as well? This would also then keep (stupid/static) sec
scans silent in regard to https://nvd.nist.gov/vuln/detail/CVE-2017-5929
Thanks
-Original Message-
From: J. D. Jordan
Sent: Dienstag, 14. Dezember 2021 16:27
To: dev@cassandra.apache.org
Subject: Re: Recent
Doesn’t hurt to upgrade. But no exploit there as far as I can see? If someone
can update your config files to point them to JNDI, you have worse problems
than that. Like they can probably update your config files to just completely
open up JMX access or what ever also.
> On Dec 14, 2021, at 9
The POC seems to require the attacker be able to upload a file that
overwrites the configuration, with hot reloading enabled. We do have
hot reloading enabled but there's no inherent way to overwrite the
config.
That said with logback currently at 1.2.3 (in trunk), perhaps we
should consider an u
Any thoughts what the logback folks have been filed here?
https://jira.qos.ch/browse/LOGBACK-1591
Thanks!
-Original Message-
From: Brandon Williams
Sent: Sonntag, 12. Dezember 2021 18:56
To: dev@cassandra.apache.org
Subject: Recent log4j vulnerability
I replied to a user- post about thi
Happy Tuesday Morning and Afternoon, which is almost Monday!
Benjamin took the time to put together a roadmap (Awesome!) for the next
Cassandra release - check that out here:
https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap
[New contributors getting started]
We have a seasonally cal
>
> Merge commits aren’t that useful
>
I keep coming back to this. Arguably the only benefit they offer now is
procedurally forcing us to not miss a bugfix on a branch, but given how
much we amend many things presently anyway that dilutes that benefit.
Having 1/3rd of your commit history be nois
+1 to cut 4.1 in May. It would be great to attain the yearly cut cadence if
possible.
Em ter., 14 de dez. de 2021 às 09:45, Mick Semb Wever
escreveu:
> > We cut 4.0 in May and released it in July. It is difficult to plan for a
> release date so we should probably agree on the cut date. One year
> We cut 4.0 in May and released it in July. It is difficult to plan for a
release date so we should probably agree on the cut date. One year after
4.0 that would make us cut the new branch in May.
This makes sense to me. The time between each rc1 cut is the only
thing we control. We want the rc1
Hi everybody,
I believe that we never really clarified when the next release should
happen. We agreed on a yearly frequency but did not go down on the details.
It might be worth it to clarify them so that we are sure that everybody is
on the same line.
We cut 4.0 in May and released it in July. I
16 matches
Mail list logo
