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

There is an INFRA issue , we're on it. On Fri, Oct 11, 2024 at 4:59 AM Stephen Webb wrote: > Is anyone able to shed light on what is going on? > > Thanks > Stephen Webb >

Re: Successor to mailing lists

Right, like having shared concepts... or shared architectural principles. Gary On Thu, Oct 10, 2024 at 5:36 PM Robert Middleton wrote: > The one problem I see with Github is that as far as I am aware > discussions are on a per-repository basis, so unless we have a bare > repository with everybo

Re: Successor to mailing lists

and some of our guys cannot reach github due to network/law reasons. Gary Gregory 于2024年10月10日周四 20:00写道： > I thought this was recently discussed on @members, but now I can't find the > thread! I'm not even sure if it was on @members, which exemplifies the > scaling problem discussed on the list

Re: Successor to mailing lists

I cannot express an opinion without knowing what the replacement is and having experience with it. Mailing lists have one great feature - they are easy to search. For that reason anything we choose should be just as easy or better. We must also stick to a single medium for formal communication f

Re: Successor to mailing lists

I thought this was recently discussed on @members, but now I can't find the thread! I'm not even sure if it was on @members, which exemplifies the scaling problem discussed on the list, among other issues: When you look at PonyMail's UI, there are about 60 internal mailing lists under the ' apache.

Re: Successor to mailing lists

GitHub can be configured to send email notifications. We can route these to, say, `notificati...@logging.apache.org` email address to have our local records. On Thu, Oct 10, 2024 at 2:01 PM Gary Gregory wrote: > I thought this was recently discussed on @members, but now I can't find the > thread

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

Is anyone able to shed light on what is going on? Thanks Stephen Webb

Re: Successor to mailing lists

Hi I am generally open to such experiments. I would start with the easiest parts, such as users@, and see where it goes. I would advise against mirroring it to users@ behind the scenes, as it may cause privacy problems (we need user consensus to mirror it). When a user uses GitHub, they know

[RESULT] [VOTE] Move Flume to dormant

Hello, this vote has completed with 5 +1 from: Piotr, Volkan, Jan, Dominik, Christian and 1 -1 from Ralph. Since we have not had any changes in the past 8 days that responds to this: https://lists.apache.org/thread/b6ndsy30j239s3fw0o2tqwm9cwmv3801 I will proceed with moving the project to the d

[log4j] Switching the default Thread Context Map impl. to GC-free one

The GC-free Thread Context Map has been an opt-in feature. I would like to make it the default if userConfiguredThreadContextMap == null && !IS_WEB_APP && ENABLE_THREADLOCALS Objections?

Re: [log4j] Switching the default Thread Context Map impl. to GC-free one

Maybe. I will have to look at it and I can’t get to it until a bit later. Ralph > On Oct 10, 2024, at 11:16 AM, Volkan Yazıcı wrote: > > The GC-free Thread Context Map has been an opt-in feature. I would like to > make it the default if > > userConfiguredThreadContextMap == null >&& !I

Re: Feature proposal for a new Filter result: Throw

Hi Gary, On Wed, 9 Oct 2024 at 16:34, Gary D. Gregory wrote: > My proposal is to allow a user to _not_ define any custom filters by reusing > a new Result enum value called “Throw”. When a filter returns “Throw”, then > Log4j throws a new LoggingException subclass called FilterLoggingException.

Successor to mailing lists

*Abstract:* Modern email system security measures make it practically impossible for mailing lists to work – many subscribers don't get all emails. This not only hinders communication, but blocks an inclusive one. *Shall we, as Logging Services, experiment with alternatives?* *Motivation #1: maili

Re: Bridges in 2.x and 3.x

I am in favor of the rebranding approach and covering all bridges. That is, I suggest adding new modules to `2.x` with bullet-proof self-explanatory names, e.g., - `*log4j-api*-to-slf4j` - `slf4j-to-*log4j-api*` – It is clear that this is an API-to-API bridge. Nobody can cry with *"Oh! Ge

Re: Successor to mailing lists

The one problem I see with Github is that as far as I am aware discussions are on a per-repository basis, so unless we have a bare repository with everybody subscribed to it there's no way that I'm aware of to share information. For example while most of this mailing list is log4j specific, we als