Re: [VOTE] Release Apache Log4cxx 1.3.0

Hi Stephen, On Tue, 15 Oct 2024 at 06:33, Stephen Webb wrote: > Review kit: > https://github.com/apache/logging-log4cxx/admin/release-review-instructions.md There is a small typo, the correct URL is: https://github.com/apache/logging-log4cxx/blob/master/admin/release-review-instructions.md For

[VOTE] Release Apache Log4cxx 1.3.0

This is a vote to release the Apache Log4cxx 1.3.0. Website: https://logging.staged.apache.org/log4cxx/1.3.0/changelog.html GitHub: https://github.com/apache/logging-log4cxx Commit: 1370eee2c19bdc287b7aa98892af02fd136694e7 Distribution: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ Signi

Re: Subpages of logging.staged.apache.org report error 404

Chris advises that all the subpage directory were empty. We will have to push whitespace commits to all the sub repos that publish content. On Fri, Oct 11, 2024 at 5:56 PM Volkan Yazıcı wrote: > There is an INFRA issue >, > we're on it. > > O

Re: [log4j] Using `DateTimeFormatter` by default

Wow. I didn’t expect them to be that much faster. That makes me very reluctant to be ok with switching. Ralph > On Oct 14, 2024, at 1:51 PM, Volkan Yazıcı wrote: > > Some results using Java 17: > > > *-MM-dd'T'HH:mm:ss.SSS*DateTimeFormatter 2.844 ± 0.310 ops/ms > FastDateFormat

Re: Successor to mailing lists

That’s because a lot of other things are also using Slack. On the other hand, I had to disable notifications from Slack due to people misusing it to DM me instead of sending emails to the Secretary properly (unrelated to Log4j). > On Oct 14, 2024, at 15:53, Ralph Goers wrote: > > I can’t say I

Re: Successor to mailing lists

I can’t say I agree with that. It didn’t take me very long to get used to using Slack. Ralph > On Oct 14, 2024, at 1:47 PM, Matt Sicker wrote: > > There’s a very, very small chance I’ll ever remember to visit a website to > find out about what are essentially emails that could have been sent

Re: [log4j] Using `DateTimeFormatter` by default

Some results using Java 17: *-MM-dd'T'HH:mm:ss.SSS*DateTimeFormatter 2.844 ± 0.310 ops/ms FastDateFormat 6.847 ± 1.302 ops/ms FixedDateFormat 39.497 ± 6.423 ops/ms *HH:mm:ss.SSS* DateTimeFormatter 3.881 ± 0.447 ops/ms FastDateFormat10.862 ± 1.915 ops/ms FixedDateFormat 39.

Re: [log4j] Using `DateTimeFormatter` by default

I think it would make sense to switch to the standard Java one. The custom classes mostly predated Java 8, and I’ve seen enough test failures whenever daylight saving time starts or ends to know that they’re buggy. > On Oct 14, 2024, at 14:30, Volkan Yazıcı wrote: > > *Abstract:* Log4j contain

Re: Successor to mailing lists

There’s a very, very small chance I’ll ever remember to visit a website to find out about what are essentially emails that could have been sent to me. I have a regular habit of reading email nearly every day, but developing new habits is unlikely to stick. > On Oct 14, 2024, at 14:50, Ralph Goe

Re: Successor to mailing lists

python...sigh. 发件人: Gary Gregory 发送时间: 星期二, 十月 15, 2024 3:59:10 上午 收件人: Apache Logging Developers List 主题: Re: Successor to mailing lists I'll admit that I rely on PonyMail. It seems we (Apache) should have a professional (paid for is ok) set up for this, not a

Re: Successor to mailing lists

I'll admit that I rely on PonyMail. It seems we (Apache) should have a professional (paid for is ok) set up for this, not a custom solution. Gary On Mon, Oct 14, 2024, 3:51 PM Ralph Goers wrote: > Maybe we just need to start contributing to PonyMail to improve the UI to > eliminate actually nee

Re: Successor to mailing lists

Maybe we just need to start contributing to PonyMail to improve the UI to eliminate actually needing the email delivered to our accounts. I am only 1/4 serious about this. There has to be a better solution. Ralph > On Oct 14, 2024, at 10:25 AM, Matt Sicker wrote: > > I didn’t get the original

Re: [log4j] Using `DateTimeFormatter` by default

Before I can weigh in one way or another I would need to know what the performance difference is between DateTimeFormatter and the Fixed and Fast classes, at least where they are working properly. Any such test should include the caching otherwise you would be comparing worst case performance.

[log4j] Using `DateTimeFormatter` by default

*Abstract:* Log4j contains two custom date & time formatting classes. All our competitors (Logback , Tinylog

Re: Unified release procedure in Apache Logging Services projects

-1 - In "Staging a release", -1 for replacing a platform-independent `pom.xml` snippet with OS-specific shell scripts - In "Reviewing a release", you say "Since the de facto source archive is the Git repository". On the contrary, as much as Legal is concerned, de facto source archiv

Re: Successor to mailing lists

I didn’t get the original email in this thread once again, so I think I’d support trying somewhere else to host discussions. Besides archiving those messages into a mailing list, it would be great if the solution provided allowed for email interactivity (e.g., you can reply to the notification o

Unified release procedure in Apache Logging Services projects

Hi all, Recently on `security-discuss@community` Christopher Schultz posted a list[0] of security-related aspects that could be improved in Apache projects. After looking at the new Log4cxx release[1] and release review[2] instructions, that I tried to automatise in PR #414[3], I am wondering if w

Re: Disable JIRA issue creation

+1 On 2024-10-14 12:12, Piotr P. Karwasz wrote: Hi all, What do you think about disabling the creation of new JIRA issues for LOG4J2? I confirmed with INFRA that this is technically possible. Disabling new issues would prevent JIRA users from filing new reports against LOG4J2. Personally I look

Re: Disable JIRA issue creation

+1 On Mon, Oct 14, 2024 at 12:12 PM Piotr P. Karwasz wrote: > Hi all, > > What do you think about disabling the creation of new JIRA issues for > LOG4J2? I confirmed with INFRA that this is technically possible. > Disabling new issues would prevent JIRA users from filing new reports > against LO

Re: Disable JIRA issue creation

+1 On 14 October 2024 12:12:10 CEST, "Piotr P. Karwasz" wrote: >Hi all, > >What do you think about disabling the creation of new JIRA issues for >LOG4J2? I confirmed with INFRA that this is technically possible. >Disabling new issues would prevent JIRA users from filing new reports >against LOG4

Disable JIRA issue creation

Hi all, What do you think about disabling the creation of new JIRA issues for LOG4J2? I confirmed with INFRA that this is technically possible. Disabling new issues would prevent JIRA users from filing new reports against LOG4J2. Personally I look at JIRA sporadically and only to look for referenc