[GitHub] [logging-log4j1] garydgregory closed pull request #19: Suji04 patch 12

[GitBox]

garydgregory closed pull request #19:
URL: https://github.com/apache/logging-log4j1/pull/19


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [logging-log4j1] garydgregory commented on pull request #19: Suji04 patch 12

[GitBox]

garydgregory commented on pull request #19:
URL: https://github.com/apache/logging-log4j1/pull/19#issuecomment-1079988268


   Hello @Suji04 
   This repository is not open for business. Please use Log4j 2.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Fwd: [NOTICE] Introducing GitHub Actions build status notification for git repositories.

[Volkan Yazıcı]

In a nutshell, we can configure `.asf.yaml` to email build status. I want
to enable this feature on both `release-2.x` and `master` and point it to `
notificati...@logging.apache.org`. Objections?

-- Forwarded message -
From: Daniel Gruno 
Date: Sat, Mar 26, 2022 at 9:58 PM
Subject: [NOTICE] Introducing GitHub Actions build status notification for
git repositories.
To: 


Dear Apache projects,
We are happy to announce yet another feature in our beloved .asf.yaml
file, namely GitHub Actions build status emails. As the name suggests,
these are emails that notify of either a failed build using GitHub
Actions, or a change from failure in previous builds to a successful
build. Continuously successful builds will not trigger emails, as that
could be rather spammy.

If your project uses GitHub Actions and wishes to enable status
notification emails, please see our documentation on this at:
https://s.apache.org/asfyaml-gha

In short, what you need to do is add a 'jobs' directive to your existing
notifications section in .asf.yaml if you have such a file (or create it
if you want this feature), for example:

notifications:
   jobs:  d...@foobar.apache.org

We hope this feature will help our projects, and look forward to any
feedback you may have, at: us...@infra.apache.org

With regards,
Daniel on behalf of the ASF Infra Team.


PS: Do note that this does not apply to subversion mirrors on GitHub,
notificati...@logging.apache.org
as .asf.yaml is not enabled for these repositories.

Re: [NOTICE] Introducing GitHub Actions build status notification for git repositories.

[Matt Sicker]

I think it’s a good idea. We used to get notifications of Jenkins build 
failures, so this would be a great substitute for that.
—
Matt Sicker

> On Mar 27, 2022, at 15:41, Volkan Yazıcı  wrote:
> 
> In a nutshell, we can configure `.asf.yaml` to email build status. I want
> to enable this feature on both `release-2.x` and `master` and point it to `
> notificati...@logging.apache.org `. 
> Objections?
> 
> -- Forwarded message -
> From: Daniel Gruno mailto:humbed...@apache.org>>
> Date: Sat, Mar 26, 2022 at 9:58 PM
> Subject: [NOTICE] Introducing GitHub Actions build status notification for
> git repositories.
> To: mailto:annou...@infra.apache.org>>
> 
> 
> Dear Apache projects,
> We are happy to announce yet another feature in our beloved .asf.yaml
> file, namely GitHub Actions build status emails. As the name suggests,
> these are emails that notify of either a failed build using GitHub
> Actions, or a change from failure in previous builds to a successful
> build. Continuously successful builds will not trigger emails, as that
> could be rather spammy.
> 
> If your project uses GitHub Actions and wishes to enable status
> notification emails, please see our documentation on this at:
> https://s.apache.org/asfyaml-gha
> 
> In short, what you need to do is add a 'jobs' directive to your existing
> notifications section in .asf.yaml if you have such a file (or create it
> if you want this feature), for example:
> 
> notifications:
> jobs: d...@foobar.apache.org
> 
> We hope this feature will help our projects, and look forward to any
> feedback you may have, at: us...@infra.apache.org
> 
> With regards,
> Daniel on behalf of the ASF Infra Team.
> 
> 
> PS: Do note that this does not apply to subversion mirrors on GitHub,
> notificati...@logging.apache.org 
> as .asf.yaml is not enabled for these repositories.

The roadmap to Log4j 3.0.0

[Matt Sicker]

Hey all, after making a lot of serious progress toward what I’ve been 
alternatively referring to as the “Mean Bean Machine” or the “Great Inversion”, 
I’m finally coming to a logical conclusion of this (only have a couple 
remaining plugin types to refactor). While it took a few tries using different 
APIs and approaches to using dependency injection, I’m feeling good about this 
current iteration as it’s been fairly successful so far at applying inversion 
of control to places that were otherwise using ad hoc configuration mechanisms 
or other static method factories to enable a unified approach to configuring 
things.

With this in place, I believe we only have a few remaining high level tasks to 
complete before we can release 3.0.0 (including any potential early-release 
alpha/beta versions). Please feel free to comment on any of these or add other 
items.

* The log4j-core module still needs to be further broken into modules such that 
log4j-core only requires java.base (and log4j-api and log4j-plugins).
* The rest of the Log4j modules that don’t already have a module-info.java file 
need one.
* There are dozens (possibly hundreds) of commits that have only been applied 
to release-2.x which need to be copied to master.
* The new JSON configuration factory based on an embedded JSON parser (from the 
JSON Template Layout module) needs to be merged into log4j-core to replace the 
Jackson variant (which would be moved to its own module just like the other 
configuration factories that require more than java.base).
* The LoggerContext properties configuration proposal from Ralph needs to be 
implemented.
* The website and docs need to be updated, though this task is shared with the 
same issue for 2.x.

Based on these remaining issues to resolve, I’d estimate that we can most 
likely make a 3.0.0 release before ApacheCon this year (which is Oct 3-6) which 
could make great timing for getting a talk or two accepted at ApacheCon (the 
first and last time I had a talk accepted for this was for the 2.0 release). If 
that’s the case, then I also have a tentative schedule we can try to follow:

1. Make an alpha or beta release of 3.0.0 by June.
2. Preferably more than one beta depending on feedback.
3. Work on cutting 3.0.0 by September.

Hopefully this timeline isn’t overly optimistic, but I believe we’ve finally 
passed some of the toughest parts of the roadmap (Java modules and the Great 
Inversion being two of them). It’d also be great to try to have a Log4j release 
with a Java 11 baseline before Java 11 itself is EOL, but that’s not a 
_requirement_ per se.
—
Matt Sicker