Re: Switch Log4j to GitHub Issues
What I like best about switching to GitHub is dealing with fewer or zero spam tickets. I will also relay that I've had push back in the past from folks who refuse to get a GitHub account in order to provide PRs. I have no idea how we can integrate changes.xml with GitHub, maybe that's something the Maven plugin already supports. Gary On Fri, Nov 4, 2022, 19:00 Ralph Goers wrote: > I’d like to know how we can get GitHub issue links included into the > release info. Can we continue to use changes.xml? > > How are we going to handle issues already in Jira? We currently have 898 > open issues. My guess is we will be lucky to ever get to 10% of them. But > how do we lock down Jira while being able to work on those issues? > > Ralph > > > On Nov 4, 2022, at 10:07 AM, Matt Sicker wrote: > > > > Usage on a phone is certainly a nice advantage for GH. Same with the MFA > integration, though the ASF is working on integrating MFA with the rest of > their offered services over time. And it does make it easier for users to > submit issues now that Jira is restricted. > > > > We might want some method for people to submit bug reports who don’t > want to use GitHub, though that doesn’t need to be too formal (maybe just > emailing dev@). > > > >> On Nov 4, 2022, at 11:55 AM, Carter Kozak wrote: > >> > >> I’m supportive of using GitHub issues for a few reasons: > >> It’s more inclusive to our users who can no longer create jira accounts. > >> My account is more secure, requiring hardware tokens to log in. > >> Unlike jira, it renders correctly on my phone. > >> > >> -ck > >> > >>> On Nov 4, 2022, at 09:43, Matt Sicker wrote: > >>> > >>> I’m fairly neutral on the change. At least you can reply to GitHub > Issue emails and have them added to the conversation (like with PRs). We > don’t really use any fancy Jira features that aren’t also available in > GitHub. > >>> > On Nov 4, 2022, at 9:06 AM, Volkan Yazıcı wrote: > > Given the last update from INFRA that new JIRA accounts will only be > allowed through (PMC?) approval, I propose switching Log4j issue > tracking > to GitHub Issues. Do you have any objections? If not, I volunteer to > create > a ticket for this and implement it. > > What needs to be done for Log4j? > - Update[1] docs, READMEs, Confluence, POM files, anywhere JIRA is > mentioned > - See if `changes.xml` et al. still functions > > [1] While updating, I will keep a reference to JIRA too, wherever > necessary. > >>> > >> > > > >
Re: Switch Log4j to GitHub Issues
+1 for to guthub issues. well if people still care about jira we can try make a jira plugin to auto create jira issue for every pr. But I really doubt if there be many people really love jira that much... From: Gary Gregory Sent: Sunday, November 6, 2022 1:59:20 AM To: Apache Logging Developers List Subject: Re: Switch Log4j to GitHub Issues What I like best about switching to GitHub is dealing with fewer or zero spam tickets. I will also relay that I've had push back in the past from folks who refuse to get a GitHub account in order to provide PRs. I have no idea how we can integrate changes.xml with GitHub, maybe that's something the Maven plugin already supports. Gary On Fri, Nov 4, 2022, 19:00 Ralph Goers wrote: > I’d like to know how we can get GitHub issue links included into the > release info. Can we continue to use changes.xml? > > How are we going to handle issues already in Jira? We currently have 898 > open issues. My guess is we will be lucky to ever get to 10% of them. But > how do we lock down Jira while being able to work on those issues? > > Ralph > > > On Nov 4, 2022, at 10:07 AM, Matt Sicker wrote: > > > > Usage on a phone is certainly a nice advantage for GH. Same with the MFA > integration, though the ASF is working on integrating MFA with the rest of > their offered services over time. And it does make it easier for users to > submit issues now that Jira is restricted. > > > > We might want some method for people to submit bug reports who don’t > want to use GitHub, though that doesn’t need to be too formal (maybe just > emailing dev@). > > > >> On Nov 4, 2022, at 11:55 AM, Carter Kozak wrote: > >> > >> I’m supportive of using GitHub issues for a few reasons: > >> It’s more inclusive to our users who can no longer create jira accounts. > >> My account is more secure, requiring hardware tokens to log in. > >> Unlike jira, it renders correctly on my phone. > >> > >> -ck > >> > >>> On Nov 4, 2022, at 09:43, Matt Sicker wrote: > >>> > >>> I’m fairly neutral on the change. At least you can reply to GitHub > Issue emails and have them added to the conversation (like with PRs). We > don’t really use any fancy Jira features that aren’t also available in > GitHub. > >>> > On Nov 4, 2022, at 9:06 AM, Volkan Yazıcı wrote: > > Given the last update from INFRA that new JIRA accounts will only be > allowed through (PMC?) approval, I propose switching Log4j issue > tracking > to GitHub Issues. Do you have any objections? If not, I volunteer to > create > a ticket for this and implement it. > > What needs to be done for Log4j? > - Update[1] docs, READMEs, Confluence, POM files, anywhere JIRA is > mentioned > - See if `changes.xml` et al. still functions > > [1] While updating, I will keep a reference to JIRA too, wherever > necessary. > >>> > >> > > > >
[log4j] Overhauling API initialization in Log4j 3.x
After an attempt at soloing the idea, I’ve reverted my changes and am instead documenting the current system along with adding some proposals in the following Confluence doc [0]. I’ve analyzed the initialization ordering of the API (without going into detail of how log4j-core initializes as this differs fairly significantly in 2.x and 3.x at this point). Right now, some of the main differences between 2.x and master is that most of the documented static fields from initialization are currently refactored into Lazy static fields, though that only defers initialization until slightly later. I’d like to work on a proper SPI here so that I can get back to considering updates to log4j-core and dependency injection. In general, my idea is to add a getInstance(Class) method to the API provider class which would be used to get the LoggerContextFactory along with initial instances for ThreadContextMap and ThreadContextFactory. This could become a natural place to also return a PropertyEnvironment instance (the interface that PropertiesUtil now implements) to further avoid use of static state. Let me know what you think of the idea. Do we need a separate log4j-spi module? Other ideas? [0]: https://cwiki.apache.org/confluence/display/LOGGING/API+Initialization — Matt Sicker
