Supported Cassandra version

[Piotr P. Karwasz]

Hi all,

As Dependabot often reminds us[1], Cassandra has a new 4.x major
version and version 3.x will reach end-of-life at the end of the
year[2].
The appender is either perfect or rarely used: the last SO question
about it is 2 years old[3] and the last issue from last year[4].

Should we create a `log4j-cassandra4` module for the next 2.x release?
Personally I would wait until we create an `l-l-cassandra` repo and
migrate the appender there, but I can probably update the code to work
with version 4.x.

Piotr

[1] https://github.com/apache/logging-log4j2/pull/1540
[2] 
https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html
[3] 
https://stackoverflow.com/search?tab=newest&q=(%5blog4j%5d%20or%20%5blog4j2%5d)%20and%20cassandra&searchOn=3
[4] https://issues.apache.org/jira/browse/LOG4J2-3553

Re: Supported Cassandra version

[Gary Gregory]

I think we can wait.

Gary

On Mon, Jul 17, 2023, 10:59 Piotr P. Karwasz 
wrote:

> Hi all,
>
> As Dependabot often reminds us[1], Cassandra has a new 4.x major
> version and version 3.x will reach end-of-life at the end of the
> year[2].
> The appender is either perfect or rarely used: the last SO question
> about it is 2 years old[3] and the last issue from last year[4].
>
> Should we create a `log4j-cassandra4` module for the next 2.x release?
> Personally I would wait until we create an `l-l-cassandra` repo and
> migrate the appender there, but I can probably update the code to work
> with version 4.x.
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j2/pull/1540
> [2]
> https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html
> [3]
> https://stackoverflow.com/search?tab=newest&q=(%5blog4j%5d%20or%20%5blog4j2%5d)%20and%20cassandra&searchOn=3
> [4] https://issues.apache.org/jira/browse/LOG4J2-3553
>

Re: Supported Cassandra version

[Volkan Yazıcı]

No, please don't add a `log4j-cassandra4` module. We haven't seen a single
sign that it is actually being used, putting aside whether the size of that
user base justifies an official Log4j module or not. If it would be up to
me, I would even drop the Cassandra support in `main`. I suppose moving
Cassandra support to a separate module and letting it rot there is the only
solution all PMC members agree on.

On Mon, Jul 17, 2023 at 4:59 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> As Dependabot often reminds us[1], Cassandra has a new 4.x major
> version and version 3.x will reach end-of-life at the end of the
> year[2].
> The appender is either perfect or rarely used: the last SO question
> about it is 2 years old[3] and the last issue from last year[4].
>
> Should we create a `log4j-cassandra4` module for the next 2.x release?
> Personally I would wait until we create an `l-l-cassandra` repo and
> migrate the appender there, but I can probably update the code to work
> with version 4.x.
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j2/pull/1540
> [2]
> https://cassandra.apache.org/_/blog/Apache-Cassandra-3.0.x-and-3.11.x-End-of-Life-Announcement.html
> [3]
> https://stackoverflow.com/search?tab=newest&q=(%5blog4j%5d%20or%20%5blog4j2%5d)%20and%20cassandra&searchOn=3
> [4] https://issues.apache.org/jira/browse/LOG4J2-3553
>

Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Volkan Yazıcı]

Vladimir, this PR  merged by
Legal updated the release policy as follows:

> It MUST be signed by either the Release Manager or the automated release
> infrastructure, where the underlying implementation MUST follow the
principles
> [outlined](/dev/release-signing.html#automated-release-signing) by the
Apache
> Security Team.

I presume your concerns regarding the signing process is addressed.

On Mon, Jul 3, 2023 at 1:13 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
>


On Mon, Jul 3, 2023 at 1:13 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> -1, don't release, because...
>
>
> Volkan,
>
> I have downloaded the release artifact apache-log4j-tools-0.4.0.zip, and I
> fail to find the source package there.
> Would you please advise?
>
> See
>
> https://www.apache.org/legal/release-policy.html#what-must-every-release-contain
>
> >Every ASF release must contain a source package, which must be sufficient
> for a user to build and
> >test the release provided they have access to the appropriate platform and
> tools
>
> I performed unzip apache-log4j-tools-0.4.0.zip, and I find two jar files,
> LICENSE, NOTICE, and RELEASE-NOTES there.
>
> The jar files contain binary/bytecode files, and the release contains no
> signs of a source package.
>
> Please, correct me if I am wrong, but it sounds that "0.4.0 release of
> Apache Log4j Tools" violates
> "WHAT MUST EVERY ASF RELEASE CONTAIN?" policy.
>
> ---
>
> > I simplified the VOTE email to *only* include details necessary for an
> > ASF-compliant release.
>
> It is unfair to omit the link to the published binary/bytecode packages.
> For instance, if the version in maven publication was different from 0.4.0,
> then it would
> violate the ASF policy.
>
> The ASF policy does impose several MUST requirements on the released
> binary/bytecode packages, see
> https://www.apache.org/legal/release-policy.html#compiled-packages
>
> >the binary/bytecode package MUST have the same version number as the
> source release
> >and MUST only add binary/bytecode files that are the result of compiling
> that version of
> >the source code release and its dependencies.
>
> ---
>
> >Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Could you please clarify who owns and controls the key?
> Correct me if I am wrong, however, the ASF release policy requires that
> the releases MUST be signed by Release Manager:
> https://www.apache.org/legal/release-policy.html#release-signing
>
> At the same time they say:
> https://www.apache.org/legal/release-policy.html#owned-controlled-hardware
>
> >hardware owned and controlled by the committer. That means hardware the
> committer has physical possession
> >and control of and exclusively full administrative/superuser access to.
> That's because only such hardware
> >is qualified to hold a PGP private key, and the release should be verified
> on the machine the private key lives on or on a machine as trusted as that
>
> It sounds to me that external systems, including GitHub Actions should not
> be trusted to store signing private keys.
> In other words, if the only PGP signature comes from a bot running in
> GitHub Actions,
> then it looks to me the release deviates from the ASF Release Policy.
>
> ---
>
> >This is a lazy vote to release
>
> Could you please clarify what do you mean by "This is a lazy vote to
> release"?
> The only thing coming to my mind is "lazy consensus", however I do not
> think lazy consensus
> can be used for release voting.
> The ASF policy requires that every time a member of PMC votes, they are
> REQUIRED to download all signed code
> onto their hardware and verify it:
> https://www.apache.org/legal/release-policy.html#release-approval
>
> Could you please clarify the meaning of "lazy" in both mail text and the
> subject?
>
>
> Vladimir
>