Re: Refining product feature set strategy
+1 to what Ralph said On Sat, Sep 30, 2023 at 0:56 Scott Deboy wrote: > +1 to everything Ralph said. > > On Fri, Sep 29, 2023, 3:53 PM Ralph Goers > wrote: > > > I’m sorry, I can’t really agree with much of any of this. Following the > > thoughts being proposed in this thread much of Log4j 2 and even the > initial > > work I did to create it would not have seen the light of day. Almost 100% > > of the stuff Matt has done would never have happened. > > > > It is a fact that people come and go from projects. Some stay longer than > > others. We have had PMC members who disappeared the day after they were > > elected to the PMC. Remko arguably made two of the most significant > > contributions in the GC-Free and Async work. Yet he has largely gone > > inactive. It happens. Even after accepting the JsonTemplateLayout and > > Volkan as a committer we had no guarantee he would stick around. We hoped > > he would and he did. Gary and I have each contributed a large number of > > components because they met some need we have/had and we continue to > > support them. > > > > Requiring hoops that must be jumped through before stuff can be accepted > > is just a terrible idea. It does nothing but create a perception that we > > are not open to new contributions and new contributors. > > > > Yes, we can retire things. I don’t think anyone is arguing against > > retiring log4j-cassandra. I haven’t seen any arguments against > log4j-kafka. > > That is primarily because they are woefully out of date. However, there > is > > nothing wrong with a module that hasn’t had any updates in a long while > if > > it is meeting user’s needs. You are never going to know for certain home > > many users there are of a given module. That data is impossible to get. > Any > > company that has their own repository manager (which should be most) will > > download a release of an artifact from Maven Central once and it will be > > hard for you to know when they did it. The metrics Sonatype provided came > > from their security product, which not everyone purchases. Yes, you can > > make guesses from those numbers but you can’t actually know how good > those > > guesses are. > > > > In short, I am in favor of retiring things when they are no longer > > maintainable. I am completely in favor of adding new components when > they > > make sense. IOW, every contribution needs to be considered on its own > > merits. > > > > Ralph > > > > > > > > > On Sep 29, 2023, at 11:32 AM, Gary Gregory > > wrote: > > > > > > I think Jira is good enough for that, since there is transition from > > state > > > to state that can be used to shepherd issues through. RFC, JEP, all way > > too > > > heavy handed for us IMO. > > > > > > Gary > > > > > > > > > On Fri, Sep 29, 2023, 2:05 PM Matt Sicker wrote: > > > > > >> I think it could be valuable for us to establish some form of an RFC > > >> process for proposing and developing major new features. I also want > to > > >> avoid being too process-heavy here as that would also disincentivize > > >> contributions. I agree that we should try to be more data-driven to > > >> determine what features and products should have the most attention. > > >> > > >> I do like the idea of having “sample” plugins which are not > distributed > > as > > >> binaries, though, which can be used in documentation for examples of > > how to > > >> integrate your own systems. With the flexibility of the plugin system > > here, > > >> we can defer the implementation of more obscure integrations to the > end > > >> user. > > >> > > >> I will note that we do already have some level of filtering to what we > > >> include. I’ve proposed numerous features in the past that I didn’t > > pursue > > >> due to reasons raised by others or lack of interest. > > >> > > >>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı wrote: > > >>> > > >>> I want to challenge the current way of PMC determining the product > > >> feature > > >>> set and work towards a more sustainable alternative. > > >>> > > >>> Logging Services team... > > >>> > > >>> - delivers mission-critical products that are deployed at the core > of > > >>> the world-wide infrastructure (actually, in Mars too) > > >>> - is short on development resources compared to its wide range of > > >>> offerings > > >>> - deals with substantial amount of legacy > > >>> - suffers from knowledge silo > > >>> > > >>> Any IT team in this state would be really conservative on accepting > new > > >>> features and try hard to get rid of the bloat. They would react to > this > > >>> challenge by first discovering the user base, pinpointing the core > > >> values, > > >>> and then lazer-focusing the limited development resources on to the > > >> crucial > > >>> deliverables. Though we do something totally different, one can even > > say > > >>> the opposite. Below I share excerpts from recent mailing list posts. > > >>> > > >>> *"I had added [X] ... to show how to write plugins and for some > > >>>
Re: [chainsaw] Lots of commented code // Backwards compatibility?
Yes, it was mostly to get rid of the log4j1 dependency and to get rid of/update other dependencies. There are a number of parts of chainsaw that depend on log4j1 features which may or may not be relevant. Most of the UI functionality should still exist, as far as I am aware. I think some of the receivers are commented out because they depend on very old versions of libraries, so it was easier to comment them out for the time being rather than try to update them to newer dependencies. -Robert Middleton On Fri, Sep 29, 2023 at 6:14 PM Scott Deboy wrote: > I think Robert commented out most of that to get rid of the log4j1 > dependency. I'm slightly concerned we'll lose a ton of UI > functionality in that process, but it's in history if it's still > needed, so delete away if you'd like. > > For comparison, you can look at the 'chainsaw-with-log4j1-dep' branch. > > Scott > > On 9/29/23, Christian Grobmeier wrote: > > Hi, > > > > Looking through the code base, I saw lots of code that is commented. Some > > classes (maybe because of this) are not even used anymore. I only saw one > > class (ChainsawViewer), which might make sense to keep. > > > > Is it OK to remove this all? Or is there a specific reason for this? > > > > Some methods are no longer used or empty despite not being commented. I > > would also like to remove them when they don't have any purpose. Since > they > > are public, BC is no longer guaranteed. For a Standalone app like this, I > > don't consider this a problem, but I would like to know if there are any > > objections. > > > > Kind regards, > > Christian > > > > >
Re: [Discuss][VOTE] Move Chainsaw to dormant status
> On Sep 29, 2023, at 6:10 AM, Christian Grobmeier wrote: > > > On Fri, Sep 22, 2023, at 12:51, Christian Grobmeier wrote: >> On Thu, Sep 21, 2023, at 19:38, Ralph Goers wrote: >>> At this point in time I will abstain from voting. As far as I am >>> concerned only 1 vote counts - Scott’s. He has steadfastly asked that >>> the project not be retired and until he positively says he will no >>> longer maintain it I am not willing to override that. >> >> >> Agreed. I don’t think this discussion is already due for a vote. Even >> when we consider it dormant, we should consider to fix the problem. >> Unlike log4j1, chainsaw was never considered EOL. >> >> I would like to hear from Scott but also Robert, who did the last commits. > > I was just reading that message again, and would like to add something. > > I actually disagree that only one vote counts in this case. The PMC as a > whole is responsible for maintaining a component, fixing security issues etc. > If we decide to keep a component, we should be behind this decision. > > I think we should reopen this vote and discussion in a few weeks again to > see, if there actually was any maintenance (no threating here) > I think you misunderstood my position. Scott has been asked at least once a year on average on whether we should retire Chainsaw. I asked that question of him many times. Every time he has been asked he has said something to the effect of “I don’t have a lot of time but I will commit to supporting Chainsaw”. In addition others have stepped up to contribute to it to help out. So long as a component has 1 PMC member who is dedicated to maintaining a component I will not support retiring it. Ralph
Re: Refining product feature set strategy
+1 to everything Ralph said. On Fri, Sep 29, 2023, 3:53 PM Ralph Goers wrote: > I’m sorry, I can’t really agree with much of any of this. Following the > thoughts being proposed in this thread much of Log4j 2 and even the initial > work I did to create it would not have seen the light of day. Almost 100% > of the stuff Matt has done would never have happened. > > It is a fact that people come and go from projects. Some stay longer than > others. We have had PMC members who disappeared the day after they were > elected to the PMC. Remko arguably made two of the most significant > contributions in the GC-Free and Async work. Yet he has largely gone > inactive. It happens. Even after accepting the JsonTemplateLayout and > Volkan as a committer we had no guarantee he would stick around. We hoped > he would and he did. Gary and I have each contributed a large number of > components because they met some need we have/had and we continue to > support them. > > Requiring hoops that must be jumped through before stuff can be accepted > is just a terrible idea. It does nothing but create a perception that we > are not open to new contributions and new contributors. > > Yes, we can retire things. I don’t think anyone is arguing against > retiring log4j-cassandra. I haven’t seen any arguments against log4j-kafka. > That is primarily because they are woefully out of date. However, there is > nothing wrong with a module that hasn’t had any updates in a long while if > it is meeting user’s needs. You are never going to know for certain home > many users there are of a given module. That data is impossible to get. Any > company that has their own repository manager (which should be most) will > download a release of an artifact from Maven Central once and it will be > hard for you to know when they did it. The metrics Sonatype provided came > from their security product, which not everyone purchases. Yes, you can > make guesses from those numbers but you can’t actually know how good those > guesses are. > > In short, I am in favor of retiring things when they are no longer > maintainable. I am completely in favor of adding new components when they > make sense. IOW, every contribution needs to be considered on its own > merits. > > Ralph > > > > > On Sep 29, 2023, at 11:32 AM, Gary Gregory > wrote: > > > > I think Jira is good enough for that, since there is transition from > state > > to state that can be used to shepherd issues through. RFC, JEP, all way > too > > heavy handed for us IMO. > > > > Gary > > > > > > On Fri, Sep 29, 2023, 2:05 PM Matt Sicker wrote: > > > >> I think it could be valuable for us to establish some form of an RFC > >> process for proposing and developing major new features. I also want to > >> avoid being too process-heavy here as that would also disincentivize > >> contributions. I agree that we should try to be more data-driven to > >> determine what features and products should have the most attention. > >> > >> I do like the idea of having “sample” plugins which are not distributed > as > >> binaries, though, which can be used in documentation for examples of > how to > >> integrate your own systems. With the flexibility of the plugin system > here, > >> we can defer the implementation of more obscure integrations to the end > >> user. > >> > >> I will note that we do already have some level of filtering to what we > >> include. I’ve proposed numerous features in the past that I didn’t > pursue > >> due to reasons raised by others or lack of interest. > >> > >>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı wrote: > >>> > >>> I want to challenge the current way of PMC determining the product > >> feature > >>> set and work towards a more sustainable alternative. > >>> > >>> Logging Services team... > >>> > >>> - delivers mission-critical products that are deployed at the core of > >>> the world-wide infrastructure (actually, in Mars too) > >>> - is short on development resources compared to its wide range of > >>> offerings > >>> - deals with substantial amount of legacy > >>> - suffers from knowledge silo > >>> > >>> Any IT team in this state would be really conservative on accepting new > >>> features and try hard to get rid of the bloat. They would react to this > >>> challenge by first discovering the user base, pinpointing the core > >> values, > >>> and then lazer-focusing the limited development resources on to the > >> crucial > >>> deliverables. Though we do something totally different, one can even > say > >>> the opposite. Below I share excerpts from recent mailing list posts. > >>> > >>> *"I had added [X] ... to show how to write plugins and for some > >>> consulting-related use cases"* – PMC member explaining how feature X > was > >>> released > >>> > >>> *"... stuff seems like it could be useful"* – PMC member asking to keep > >>> feature X > >>> > >>> *"my employer used [X] ... for anyone implementing ... this would be > very > >>> relevant. By archiving this we
Re: Refining product feature set strategy
I’m sorry, I can’t really agree with much of any of this. Following the thoughts being proposed in this thread much of Log4j 2 and even the initial work I did to create it would not have seen the light of day. Almost 100% of the stuff Matt has done would never have happened. It is a fact that people come and go from projects. Some stay longer than others. We have had PMC members who disappeared the day after they were elected to the PMC. Remko arguably made two of the most significant contributions in the GC-Free and Async work. Yet he has largely gone inactive. It happens. Even after accepting the JsonTemplateLayout and Volkan as a committer we had no guarantee he would stick around. We hoped he would and he did. Gary and I have each contributed a large number of components because they met some need we have/had and we continue to support them. Requiring hoops that must be jumped through before stuff can be accepted is just a terrible idea. It does nothing but create a perception that we are not open to new contributions and new contributors. Yes, we can retire things. I don’t think anyone is arguing against retiring log4j-cassandra. I haven’t seen any arguments against log4j-kafka. That is primarily because they are woefully out of date. However, there is nothing wrong with a module that hasn’t had any updates in a long while if it is meeting user’s needs. You are never going to know for certain home many users there are of a given module. That data is impossible to get. Any company that has their own repository manager (which should be most) will download a release of an artifact from Maven Central once and it will be hard for you to know when they did it. The metrics Sonatype provided came from their security product, which not everyone purchases. Yes, you can make guesses from those numbers but you can’t actually know how good those guesses are. In short, I am in favor of retiring things when they are no longer maintainable. I am completely in favor of adding new components when they make sense. IOW, every contribution needs to be considered on its own merits. Ralph > On Sep 29, 2023, at 11:32 AM, Gary Gregory wrote: > > I think Jira is good enough for that, since there is transition from state > to state that can be used to shepherd issues through. RFC, JEP, all way too > heavy handed for us IMO. > > Gary > > > On Fri, Sep 29, 2023, 2:05 PM Matt Sicker wrote: > >> I think it could be valuable for us to establish some form of an RFC >> process for proposing and developing major new features. I also want to >> avoid being too process-heavy here as that would also disincentivize >> contributions. I agree that we should try to be more data-driven to >> determine what features and products should have the most attention. >> >> I do like the idea of having “sample” plugins which are not distributed as >> binaries, though, which can be used in documentation for examples of how to >> integrate your own systems. With the flexibility of the plugin system here, >> we can defer the implementation of more obscure integrations to the end >> user. >> >> I will note that we do already have some level of filtering to what we >> include. I’ve proposed numerous features in the past that I didn’t pursue >> due to reasons raised by others or lack of interest. >> >>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı wrote: >>> >>> I want to challenge the current way of PMC determining the product >> feature >>> set and work towards a more sustainable alternative. >>> >>> Logging Services team... >>> >>> - delivers mission-critical products that are deployed at the core of >>> the world-wide infrastructure (actually, in Mars too) >>> - is short on development resources compared to its wide range of >>> offerings >>> - deals with substantial amount of legacy >>> - suffers from knowledge silo >>> >>> Any IT team in this state would be really conservative on accepting new >>> features and try hard to get rid of the bloat. They would react to this >>> challenge by first discovering the user base, pinpointing the core >> values, >>> and then lazer-focusing the limited development resources on to the >> crucial >>> deliverables. Though we do something totally different, one can even say >>> the opposite. Below I share excerpts from recent mailing list posts. >>> >>> *"I had added [X] ... to show how to write plugins and for some >>> consulting-related use cases"* – PMC member explaining how feature X was >>> released >>> >>> *"... stuff seems like it could be useful"* – PMC member asking to keep >>> feature X >>> >>> *"my employer used [X] ... for anyone implementing ... this would be very >>> relevant. By archiving this we are basically telling users that they >>> cannot use it any more since it will no longer be supported. For that >>> reason I am not in favor of [retiring]"* – PMC member asking to keep >>> feature X >>> >>> *"We [the employer] ... use [X]"* – PMC member
Re: [chainsaw] Lots of commented code // Backwards compatibility?
I think Robert commented out most of that to get rid of the log4j1 dependency. I'm slightly concerned we'll lose a ton of UI functionality in that process, but it's in history if it's still needed, so delete away if you'd like. For comparison, you can look at the 'chainsaw-with-log4j1-dep' branch. Scott On 9/29/23, Christian Grobmeier wrote: > Hi, > > Looking through the code base, I saw lots of code that is commented. Some > classes (maybe because of this) are not even used anymore. I only saw one > class (ChainsawViewer), which might make sense to keep. > > Is it OK to remove this all? Or is there a specific reason for this? > > Some methods are no longer used or empty despite not being commented. I > would also like to remove them when they don't have any purpose. Since they > are public, BC is no longer guaranteed. For a Standalone app like this, I > don't consider this a problem, but I would like to know if there are any > objections. > > Kind regards, > Christian > >
[chainsaw] Lots of commented code // Backwards compatibility?
Hi, Looking through the code base, I saw lots of code that is commented. Some classes (maybe because of this) are not even used anymore. I only saw one class (ChainsawViewer), which might make sense to keep. Is it OK to remove this all? Or is there a specific reason for this? Some methods are no longer used or empty despite not being commented. I would also like to remove them when they don't have any purpose. Since they are public, BC is no longer guaranteed. For a Standalone app like this, I don't consider this a problem, but I would like to know if there are any objections. Kind regards, Christian
Re: [VOTE] Release Apache Log4j Tools 0.5.0
+1 On Fri, Sep 29, 2023, at 13:13, Volkan Yazıcı wrote: > This is a vote to release the Apache Log4j Tools 0.5.0. > > Source repository: https://github.com/apache/logging-log4j-tools > Commit: 861b03c70a76ca19408ffc8c4a77bc0c4e5e4570 > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1187 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 72 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. At least 3 +1 votes and more > positive than negative votes are required. > > === Release Notes > > This minor release contains various bug fixes and improvements. > > Added > > * Started publishing the project website[1] > > [1] https://logging.staged.apache.org/log4j/tools > > Changed > > * Made `author` element optional and bumped the XML schema version to > `0.1.2` (#81) > * Make `log4j-changelog-maven-plugin` thread-safe (#80) > * Update `org.apache.logging:logging-parent` to version `10.1.0` (#82) > * Update `org.junit.jupiter:junit-jupiter-engine` to version `5.10.0`
Re: [chainsaw] Is ZeroConf support relevant?
Oh wow I was sure this is log4j1 great, I even found some docs. https://logging.apache.org/log4j/2.x/manual/configuration.html#chainsaw-can-automatically-process-your-log-files-advertising-ap Thanks! On Fri, Sep 29, 2023, at 21:40, Scott Deboy wrote: > This is a log4j2 feature. > > Scott > > On Fri, Sep 29, 2023, 12:24 PM Christian Grobmeier > wrote: > >> Volkan asked this question here: >> https://github.com/apache/logging-chainsaw/issues/24 >> >> I guess, since Log4j1 is EOL we can safely remove this feature, right? >>
Re: [chainsaw] Is ZeroConf support relevant?
This is a log4j2 feature. Scott On Fri, Sep 29, 2023, 12:24 PM Christian Grobmeier wrote: > Volkan asked this question here: > https://github.com/apache/logging-chainsaw/issues/24 > > I guess, since Log4j1 is EOL we can safely remove this feature, right? >
[chainsaw] Is ZeroConf support relevant?
Volkan asked this question here: https://github.com/apache/logging-chainsaw/issues/24 I guess, since Log4j1 is EOL we can safely remove this feature, right?
Re: Refining product feature set strategy
I think Jira is good enough for that, since there is transition from state to state that can be used to shepherd issues through. RFC, JEP, all way too heavy handed for us IMO. Gary On Fri, Sep 29, 2023, 2:05 PM Matt Sicker wrote: > I think it could be valuable for us to establish some form of an RFC > process for proposing and developing major new features. I also want to > avoid being too process-heavy here as that would also disincentivize > contributions. I agree that we should try to be more data-driven to > determine what features and products should have the most attention. > > I do like the idea of having “sample” plugins which are not distributed as > binaries, though, which can be used in documentation for examples of how to > integrate your own systems. With the flexibility of the plugin system here, > we can defer the implementation of more obscure integrations to the end > user. > > I will note that we do already have some level of filtering to what we > include. I’ve proposed numerous features in the past that I didn’t pursue > due to reasons raised by others or lack of interest. > > > On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı wrote: > > > > I want to challenge the current way of PMC determining the product > feature > > set and work towards a more sustainable alternative. > > > > Logging Services team... > > > > - delivers mission-critical products that are deployed at the core of > > the world-wide infrastructure (actually, in Mars too) > > - is short on development resources compared to its wide range of > > offerings > > - deals with substantial amount of legacy > > - suffers from knowledge silo > > > > Any IT team in this state would be really conservative on accepting new > > features and try hard to get rid of the bloat. They would react to this > > challenge by first discovering the user base, pinpointing the core > values, > > and then lazer-focusing the limited development resources on to the > crucial > > deliverables. Though we do something totally different, one can even say > > the opposite. Below I share excerpts from recent mailing list posts. > > > > *"I had added [X] ... to show how to write plugins and for some > > consulting-related use cases"* – PMC member explaining how feature X was > > released > > > > *"... stuff seems like it could be useful"* – PMC member asking to keep > > feature X > > > > *"my employer used [X] ... for anyone implementing ... this would be very > > relevant. By archiving this we are basically telling users that they > > cannot use it any more since it will no longer be supported. For that > > reason I am not in favor of [retiring]"* – PMC member asking to keep > > feature X > > > > *"We [the employer] ... use [X]"* – PMC member asking to keep feature X > > > > *"User base [is] ... very low to non-existent."* – PMC member asking to > > keep product X > > > > *"[PMC member] has steadfastly [reacted] ... and until he positively says > > he will no longer maintain it I am not willing to override that"* – PMC > > member asking to keep product X because another (one and only) PMC member > > reacted on product retirement inquiry > > > > *"Our employers are ... paying customers."* – a PMC member explaining why > > we should keep feature X used by an organization employing another PMC > > member > > > > > > I see a pattern in the way we decide to maintain a feature/product: > > > > - It is not data-driven. It is disconnected from its user base. No > usage > > statistics, etc. is shared or used. > > - We serve individuals' and employers' agendas. > > - We underestimate the cost of adding/keeping a feature. > > > > I think this diet is "unhealthy" because: > > > > - It adds up to the bloat. It is yet another component developers need > > to maintain its dependencies, documentation, website, integration with > the > > build system, etc. This bizarrely slows down the development > experience. > > (Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?) > > - It adds up to the attack surface. > > - Features that are supposed to be optional get shipped to users > without > > their consent. (Consider the percentage of the Log4Shell victims that > used > > the JNDI functionality at all.) > > - Scarce development resources get wasted on chores due to the > > excessive landscape. > > - It gives users the wrong impression that the feature/product is > > maintained, though under the hood it is just kept there because a > > privileged group wants so. > > > > I want to refine this approach with your help. To start the discussion, I > > propose the following strategy instead: > > > > *"We only accept a feature with data-driven justification."* – Have a > brand > > new idea? Grab yourself a GitHub/GitLab repository that belongs to either > > you or your employer, knock yourself out without any ASF/PMC burdens, and > > amaze your users. Once the user attraction gets enough gravity, let's > > discuss blessing
Re: Refining product feature set strategy
I think it could be valuable for us to establish some form of an RFC process for proposing and developing major new features. I also want to avoid being too process-heavy here as that would also disincentivize contributions. I agree that we should try to be more data-driven to determine what features and products should have the most attention. I do like the idea of having “sample” plugins which are not distributed as binaries, though, which can be used in documentation for examples of how to integrate your own systems. With the flexibility of the plugin system here, we can defer the implementation of more obscure integrations to the end user. I will note that we do already have some level of filtering to what we include. I’ve proposed numerous features in the past that I didn’t pursue due to reasons raised by others or lack of interest. > On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı wrote: > > I want to challenge the current way of PMC determining the product feature > set and work towards a more sustainable alternative. > > Logging Services team... > > - delivers mission-critical products that are deployed at the core of > the world-wide infrastructure (actually, in Mars too) > - is short on development resources compared to its wide range of > offerings > - deals with substantial amount of legacy > - suffers from knowledge silo > > Any IT team in this state would be really conservative on accepting new > features and try hard to get rid of the bloat. They would react to this > challenge by first discovering the user base, pinpointing the core values, > and then lazer-focusing the limited development resources on to the crucial > deliverables. Though we do something totally different, one can even say > the opposite. Below I share excerpts from recent mailing list posts. > > *"I had added [X] ... to show how to write plugins and for some > consulting-related use cases"* – PMC member explaining how feature X was > released > > *"... stuff seems like it could be useful"* – PMC member asking to keep > feature X > > *"my employer used [X] ... for anyone implementing ... this would be very > relevant. By archiving this we are basically telling users that they > cannot use it any more since it will no longer be supported. For that > reason I am not in favor of [retiring]"* – PMC member asking to keep > feature X > > *"We [the employer] ... use [X]"* – PMC member asking to keep feature X > > *"User base [is] ... very low to non-existent."* – PMC member asking to > keep product X > > *"[PMC member] has steadfastly [reacted] ... and until he positively says > he will no longer maintain it I am not willing to override that"* – PMC > member asking to keep product X because another (one and only) PMC member > reacted on product retirement inquiry > > *"Our employers are ... paying customers."* – a PMC member explaining why > we should keep feature X used by an organization employing another PMC > member > > > I see a pattern in the way we decide to maintain a feature/product: > > - It is not data-driven. It is disconnected from its user base. No usage > statistics, etc. is shared or used. > - We serve individuals' and employers' agendas. > - We underestimate the cost of adding/keeping a feature. > > I think this diet is "unhealthy" because: > > - It adds up to the bloat. It is yet another component developers need > to maintain its dependencies, documentation, website, integration with the > build system, etc. This bizarrely slows down the development experience. > (Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?) > - It adds up to the attack surface. > - Features that are supposed to be optional get shipped to users without > their consent. (Consider the percentage of the Log4Shell victims that used > the JNDI functionality at all.) > - Scarce development resources get wasted on chores due to the > excessive landscape. > - It gives users the wrong impression that the feature/product is > maintained, though under the hood it is just kept there because a > privileged group wants so. > > I want to refine this approach with your help. To start the discussion, I > propose the following strategy instead: > > *"We only accept a feature with data-driven justification."* – Have a brand > new idea? Grab yourself a GitHub/GitLab repository that belongs to either > you or your employer, knock yourself out without any ASF/PMC burdens, and > amaze your users. Once the user attraction gets enough gravity, let's > discuss blessing it as a part of the official Logging Services offering. > Official support channels are always open to assist the developers of such > external efforts. > > *"We only keep a feature with data-driven justification."* – Do you think a > feature needs to be retired? Bring it up for discussion. PMC should > evaluate the request based on numbers and this process should be > independent of the
Re: [VOTE] Release Apache Log4j Tools 0.5.0
+1 > On Sep 29, 2023, at 6:13 AM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Tools 0.5.0. > > Source repository: https://github.com/apache/logging-log4j-tools > Commit: 861b03c70a76ca19408ffc8c4a77bc0c4e5e4570 > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1187 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 72 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. At least 3 +1 votes and more > positive than negative votes are required. > > === Release Notes > > This minor release contains various bug fixes and improvements. > > Added > > * Started publishing the project website[1] > > [1] https://logging.staged.apache.org/log4j/tools > > Changed > > * Made `author` element optional and bumped the XML schema version to > `0.1.2` (#81) > * Make `log4j-changelog-maven-plugin` thread-safe (#80) > * Update `org.apache.logging:logging-parent` to version `10.1.0` (#82) > * Update `org.junit.jupiter:junit-jupiter-engine` to version `5.10.0`
Re: [chainsaw] Trouble starting it at all
On Fri, Sep 29, 2023, at 18:51, Scott Deboy wrote:
> There should be a default config. Do you have anything in the .chainsaw
> directory? If so, delete it.
Yes figured it right when I received your message.
The application created this directory. Looking into it, there were files as
chainsaw.settings.properties. These files looked incomplete.
After I deleted it, it actually worked. No idea why this was created that way.
>
> On Fri, Sep 29, 2023, 9:49 AM Christian Grobmeier
> wrote:
>
>> OK, got it running, after commenting those lines:
>>
>> //statusBar.setSelected(config.getBoolean("statusBar"));
>> statusBar.setSelected(false);
>> //receivers.setSelected(config.getBoolean("showReceivers"));
>> receivers.setSelected(false);
>> //toolBar.setSelected(config.getBoolean("toolbar"));
>> toolBar.setSelected(false);
>> //configureTabPlacement(config.getInt("tabPlacement"));
>> configureTabPlacement(1);
>>
>> Looks like the missing configuration is a problem.
>> Is there any configuration I should add to the startup?
>>
>>
>> On Fri, Sep 29, 2023, at 18:36, Christian Grobmeier wrote:
>> > I have installed Netbeans and tried it with that.
>> > I also tried Corretta 11, Zulu 11, Zulu 11 with FX. OpenJDK 11 is no
>> > longer available for me (on Mac) it seems.
>> >
>> > Still no success. The splash opens, but no further movement.
>> >
>> > I have two errors earlier, but I don't think they break anything:
>> >
>> > ERROR org.apache.log4j.chainsaw.LogUI - Uncaught exception in thread
>> > Thread[AWT-EventQueue-0,6,main]
>> > java.util.NoSuchElementException: Key 'statusBar' does not map to an
>> > existing object!
>> > at
>> >
>> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>>
>> > ~[commons-configuration2-2.7.jar:2.7]
>> > at
>> >
>> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>>
>> > ~[commons-configuration2-2.7.jar:2.7]
>> >
>> > and the underlying cause is printed extra:
>> >
>> > java.util.NoSuchElementException: Key 'statusBar' does not map to an
>> > existing object!
>> > at
>> >
>> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>> > at
>> >
>> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>> >
>> >
>> > Either it is something special in the OpenJDK or maybe even related to
>> > the Mac. I assume you are on Windows. Could you try with another JDK,
>> > maybe Zulu or Correta?
>> >
>> >
>> >
>> >
>> >
>> > --
>> > The Apache Software Foundation
>> > V.P., Data Privacy
>> >
>> > On Fri, Sep 29, 2023, at 17:19, Robert Middleton wrote:
>> >> It starts up for me with Netbeans and OpenJDK 11. I would expect an
>> >> exception/stack trace to be printed to stderr if an exception was thrown
>> >> that caused it to fail to load.
>> >>
>> >> -Robert Middleton
>> >>
>> >> On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier <
>> grobme...@apache.org>
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I have found out Chainsaw requires Java 11. I used this from IntelliJ
>> and
>> >>> run LogUI.
>> >>> However, even when there is no error message, the Splash Screen never
>> >>> disappears.
>> >>> Is there any specific verion of Java I need?
>> >>>
>> >>> These are he last lines i see:
>> >>>
>> >>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> >>> org.apache.log4j.chainsaw.LogUI
>> >>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel
>> >>> 15:15:29.581 [AWT-EventQueue-0] DEBUG
>> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> >>> org.apache.log4j.chainsaw.LoggerNameTreePanel
>> >>>
>> >>> Then no further actitivty,
>> >>>
>> >>> Any ideas?
>> >>>
>> >>> --
>> >>> The Apache Software Foundation
>> >>> V.P., Data Privacy
>> >>>
>>
Re: [chainsaw] Trouble starting it at all
There should be a default config. Do you have anything in the .chainsaw
directory? If so, delete it.
On Fri, Sep 29, 2023, 9:49 AM Christian Grobmeier
wrote:
> OK, got it running, after commenting those lines:
>
> //statusBar.setSelected(config.getBoolean("statusBar"));
> statusBar.setSelected(false);
> //receivers.setSelected(config.getBoolean("showReceivers"));
> receivers.setSelected(false);
> //toolBar.setSelected(config.getBoolean("toolbar"));
> toolBar.setSelected(false);
> //configureTabPlacement(config.getInt("tabPlacement"));
> configureTabPlacement(1);
>
> Looks like the missing configuration is a problem.
> Is there any configuration I should add to the startup?
>
>
> On Fri, Sep 29, 2023, at 18:36, Christian Grobmeier wrote:
> > I have installed Netbeans and tried it with that.
> > I also tried Corretta 11, Zulu 11, Zulu 11 with FX. OpenJDK 11 is no
> > longer available for me (on Mac) it seems.
> >
> > Still no success. The splash opens, but no further movement.
> >
> > I have two errors earlier, but I don't think they break anything:
> >
> > ERROR org.apache.log4j.chainsaw.LogUI - Uncaught exception in thread
> > Thread[AWT-EventQueue-0,6,main]
> > java.util.NoSuchElementException: Key 'statusBar' does not map to an
> > existing object!
> > at
> >
> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>
> > ~[commons-configuration2-2.7.jar:2.7]
> > at
> >
> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>
> > ~[commons-configuration2-2.7.jar:2.7]
> >
> > and the underlying cause is printed extra:
> >
> > java.util.NoSuchElementException: Key 'statusBar' does not map to an
> > existing object!
> > at
> >
> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
> > at
> >
> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
> >
> >
> > Either it is something special in the OpenJDK or maybe even related to
> > the Mac. I assume you are on Windows. Could you try with another JDK,
> > maybe Zulu or Correta?
> >
> >
> >
> >
> >
> > --
> > The Apache Software Foundation
> > V.P., Data Privacy
> >
> > On Fri, Sep 29, 2023, at 17:19, Robert Middleton wrote:
> >> It starts up for me with Netbeans and OpenJDK 11. I would expect an
> >> exception/stack trace to be printed to stderr if an exception was thrown
> >> that caused it to fail to load.
> >>
> >> -Robert Middleton
> >>
> >> On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier <
> grobme...@apache.org>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I have found out Chainsaw requires Java 11. I used this from IntelliJ
> and
> >>> run LogUI.
> >>> However, even when there is no error message, the Splash Screen never
> >>> disappears.
> >>> Is there any specific verion of Java I need?
> >>>
> >>> These are he last lines i see:
> >>>
> >>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
> >>> org.apache.log4j.chainsaw.LogUI
> >>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel
> >>> 15:15:29.581 [AWT-EventQueue-0] DEBUG
> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
> >>> org.apache.log4j.chainsaw.LoggerNameTreePanel
> >>>
> >>> Then no further actitivty,
> >>>
> >>> Any ideas?
> >>>
> >>> --
> >>> The Apache Software Foundation
> >>> V.P., Data Privacy
> >>>
>
Re: [chainsaw] Trouble starting it at all
OK, got it running, after commenting those lines:
//statusBar.setSelected(config.getBoolean("statusBar"));
statusBar.setSelected(false);
//receivers.setSelected(config.getBoolean("showReceivers"));
receivers.setSelected(false);
//toolBar.setSelected(config.getBoolean("toolbar"));
toolBar.setSelected(false);
//configureTabPlacement(config.getInt("tabPlacement"));
configureTabPlacement(1);
Looks like the missing configuration is a problem.
Is there any configuration I should add to the startup?
On Fri, Sep 29, 2023, at 18:36, Christian Grobmeier wrote:
> I have installed Netbeans and tried it with that.
> I also tried Corretta 11, Zulu 11, Zulu 11 with FX. OpenJDK 11 is no
> longer available for me (on Mac) it seems.
>
> Still no success. The splash opens, but no further movement.
>
> I have two errors earlier, but I don't think they break anything:
>
> ERROR org.apache.log4j.chainsaw.LogUI - Uncaught exception in thread
> Thread[AWT-EventQueue-0,6,main]
> java.util.NoSuchElementException: Key 'statusBar' does not map to an
> existing object!
> at
> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>
> ~[commons-configuration2-2.7.jar:2.7]
> at
> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>
> ~[commons-configuration2-2.7.jar:2.7]
>
> and the underlying cause is printed extra:
>
> java.util.NoSuchElementException: Key 'statusBar' does not map to an
> existing object!
> at
> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
> at
> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>
>
> Either it is something special in the OpenJDK or maybe even related to
> the Mac. I assume you are on Windows. Could you try with another JDK,
> maybe Zulu or Correta?
>
>
>
>
>
> --
> The Apache Software Foundation
> V.P., Data Privacy
>
> On Fri, Sep 29, 2023, at 17:19, Robert Middleton wrote:
>> It starts up for me with Netbeans and OpenJDK 11. I would expect an
>> exception/stack trace to be printed to stderr if an exception was thrown
>> that caused it to fail to load.
>>
>> -Robert Middleton
>>
>> On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier
>> wrote:
>>
>>> Hi,
>>>
>>> I have found out Chainsaw requires Java 11. I used this from IntelliJ and
>>> run LogUI.
>>> However, even when there is no error message, the Splash Screen never
>>> disappears.
>>> Is there any specific verion of Java I need?
>>>
>>> These are he last lines i see:
>>>
>>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>>> org.apache.log4j.chainsaw.LogUI
>>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel
>>> 15:15:29.581 [AWT-EventQueue-0] DEBUG
>>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>>> org.apache.log4j.chainsaw.LoggerNameTreePanel
>>>
>>> Then no further actitivty,
>>>
>>> Any ideas?
>>>
>>> --
>>> The Apache Software Foundation
>>> V.P., Data Privacy
>>>
Re: [chainsaw] Trouble starting it at all
I have installed Netbeans and tried it with that. I also tried Corretta 11, Zulu 11, Zulu 11 with FX. OpenJDK 11 is no longer available for me (on Mac) it seems. Still no success. The splash opens, but no further movement. I have two errors earlier, but I don't think they break anything: ERROR org.apache.log4j.chainsaw.LogUI - Uncaught exception in thread Thread[AWT-EventQueue-0,6,main] java.util.NoSuchElementException: Key 'statusBar' does not map to an existing object! at org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902) ~[commons-configuration2-2.7.jar:2.7] at org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889) ~[commons-configuration2-2.7.jar:2.7] and the underlying cause is printed extra: java.util.NoSuchElementException: Key 'statusBar' does not map to an existing object! at org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902) at org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889) Either it is something special in the OpenJDK or maybe even related to the Mac. I assume you are on Windows. Could you try with another JDK, maybe Zulu or Correta? -- The Apache Software Foundation V.P., Data Privacy On Fri, Sep 29, 2023, at 17:19, Robert Middleton wrote: > It starts up for me with Netbeans and OpenJDK 11. I would expect an > exception/stack trace to be printed to stderr if an exception was thrown > that caused it to fail to load. > > -Robert Middleton > > On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier > wrote: > >> Hi, >> >> I have found out Chainsaw requires Java 11. I used this from IntelliJ and >> run LogUI. >> However, even when there is no error message, the Splash Screen never >> disappears. >> Is there any specific verion of Java I need? >> >> These are he last lines i see: >> >> 15:15:29.580 [AWT-EventQueue-0] DEBUG >> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map >> org.apache.log4j.chainsaw.LogUI >> 15:15:29.580 [AWT-EventQueue-0] DEBUG >> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map >> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel >> 15:15:29.581 [AWT-EventQueue-0] DEBUG >> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map >> org.apache.log4j.chainsaw.LoggerNameTreePanel >> >> Then no further actitivty, >> >> Any ideas? >> >> -- >> The Apache Software Foundation >> V.P., Data Privacy >>
Re: [VOTE] Release Apache Log4j Kotlin API 1.3.0
No. If the build would have failed, I couldn't cut the release, since it is the CI uploading artifacts + distribution to both Nexus and SVN. Probably an issue with the badge or sth else on `main`. On Fri, 29 Sep 2023, 16:24 Gary Gregory wrote: > https://github.com/apache/logging-log4j-kotlin shows the "build failing" > badge, does that matter? > > Gary > > On Thu, Sep 28, 2023, 9:25 AM Volkan Yazıcı wrote: > > > This is a vote to release the Apache Log4j Kotlin API 1.3.0. > > > > Source repository: https://github.com/apache/logging-log4j-kotlin > > Commit: b273cfb450898f079d2fd10b575330bfb900101b > > Distribution: > https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin > > Nexus: > > https://repository.apache.org/content/repositories/orgapachelogging-1186 > > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > > > Please download, test, and cast your votes on this mailing list. > > > > [ ] +1, release the artifacts > > [ ] -1, don't release, because... > > > > This vote is open for 72 hours and will pass unless getting a > > net negative vote count. All votes are welcome and we encourage > > everyone to test the release, but only the Logging Services PMC > > votes are officially counted. At least 3 +1 votes and more > > positive than negative votes are required. > > > > === Release Notes > > > > This minor release bumps the Kotlin baseline to 1.6.21 and contains > > various small improvements. > > > > Added > > > > * Added an extension property for storing a cached logger (#29) > > * Added facade APIs for manipulating the context map and stack (#30) > > * Added missing `catching` and `throwing` API methods in `KotlinLogger` > > (#32) > > * Added JPMS support and used `org.apache.logging.log4j.api_kotlin` > > for the module name (identical to OSGi `Bundle-SymbolicName`) of the > > `log4j-api-kotlin` artifact > > > > Changed > > > > * Updated Log4j dependency to `2.20.0` > > * Bumped `logging-parent` version to `10.1.0` and overhauled the > > entire project infrastructure to take advantage of its goodies (#37) > > * Renamed OSGi `Bundle-SymbolicName` from > > `org.apache.logging.log4j.kotlin` to > > `org.apache.logging.log4j.api_kotlin` > > * Migrated tests to JUnit 5 > > * Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4` > > respectively > > >
Re: [chainsaw] Trouble starting it at all
It starts up for me with Netbeans and OpenJDK 11. I would expect an exception/stack trace to be printed to stderr if an exception was thrown that caused it to fail to load. -Robert Middleton On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier wrote: > Hi, > > I have found out Chainsaw requires Java 11. I used this from IntelliJ and > run LogUI. > However, even when there is no error message, the Splash Screen never > disappears. > Is there any specific verion of Java I need? > > These are he last lines i see: > > 15:15:29.580 [AWT-EventQueue-0] DEBUG > org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map > org.apache.log4j.chainsaw.LogUI > 15:15:29.580 [AWT-EventQueue-0] DEBUG > org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map > org.apache.log4j.chainsaw.LogPanelLoggerTreeModel > 15:15:29.581 [AWT-EventQueue-0] DEBUG > org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map > org.apache.log4j.chainsaw.LoggerNameTreePanel > > Then no further actitivty, > > Any ideas? > > -- > The Apache Software Foundation > V.P., Data Privacy >
Re: [VOTE] Release Apache Log4j Kotlin API 1.3.0
https://github.com/apache/logging-log4j-kotlin shows the "build failing" badge, does that matter? Gary On Thu, Sep 28, 2023, 9:25 AM Volkan Yazıcı wrote: > This is a vote to release the Apache Log4j Kotlin API 1.3.0. > > Source repository: https://github.com/apache/logging-log4j-kotlin > Commit: b273cfb450898f079d2fd10b575330bfb900101b > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1186 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 72 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. At least 3 +1 votes and more > positive than negative votes are required. > > === Release Notes > > This minor release bumps the Kotlin baseline to 1.6.21 and contains > various small improvements. > > Added > > * Added an extension property for storing a cached logger (#29) > * Added facade APIs for manipulating the context map and stack (#30) > * Added missing `catching` and `throwing` API methods in `KotlinLogger` > (#32) > * Added JPMS support and used `org.apache.logging.log4j.api_kotlin` > for the module name (identical to OSGi `Bundle-SymbolicName`) of the > `log4j-api-kotlin` artifact > > Changed > > * Updated Log4j dependency to `2.20.0` > * Bumped `logging-parent` version to `10.1.0` and overhauled the > entire project infrastructure to take advantage of its goodies (#37) > * Renamed OSGi `Bundle-SymbolicName` from > `org.apache.logging.log4j.kotlin` to > `org.apache.logging.log4j.api_kotlin` > * Migrated tests to JUnit 5 > * Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4` > respectively >
[chainsaw] Trouble starting it at all
Hi, I have found out Chainsaw requires Java 11. I used this from IntelliJ and run LogUI. However, even when there is no error message, the Splash Screen never disappears. Is there any specific verion of Java I need? These are he last lines i see: 15:15:29.580 [AWT-EventQueue-0] DEBUG org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map org.apache.log4j.chainsaw.LogUI 15:15:29.580 [AWT-EventQueue-0] DEBUG org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map org.apache.log4j.chainsaw.LogPanelLoggerTreeModel 15:15:29.581 [AWT-EventQueue-0] DEBUG org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map org.apache.log4j.chainsaw.LoggerNameTreePanel Then no further actitivty, Any ideas? -- The Apache Software Foundation V.P., Data Privacy
Re: [Discuss][VOTE] Move Chainsaw to dormant status
On Fri, Sep 22, 2023, at 12:51, Christian Grobmeier wrote: > On Thu, Sep 21, 2023, at 19:38, Ralph Goers wrote: >> At this point in time I will abstain from voting. As far as I am >> concerned only 1 vote counts - Scott’s. He has steadfastly asked that >> the project not be retired and until he positively says he will no >> longer maintain it I am not willing to override that. > > > Agreed. I don’t think this discussion is already due for a vote. Even > when we consider it dormant, we should consider to fix the problem. > Unlike log4j1, chainsaw was never considered EOL. > > I would like to hear from Scott but also Robert, who did the last commits. I was just reading that message again, and would like to add something. I actually disagree that only one vote counts in this case. The PMC as a whole is responsible for maintaining a component, fixing security issues etc. If we decide to keep a component, we should be behind this decision. I think we should reopen this vote and discussion in a few weeks again to see, if there actually was any maintenance (no threating here) Kind regards, Christian > Christian > >> I should also note that AFAIK we have never “archived” a dormant >> project. We simply change its status on the web site. That said, a >> read-only repo does make some sense for a dormant project I guess. >> >> Ralph >> >>> On Sep 21, 2023, at 10:00 AM, Volkan Yazıcı wrote: >>> >>> As earlier discussions[1] indicate, Chainsaw has been lacking on >>> maintenance and no PMC member stepped up to perform necessary chores. >>> This is a vote to retire the Chainsaw by means of >>> >>> - Move it to the list of dormant projects[2] >>> - Making it clear in its README and website that the project is not >>> maintained anymore >>> - Archive its repository[3] >>> >>> Please cast your votes on this mailing list. >>> >>> [ ] +1, retire the project >>> [ ] -1, don't retire, because... >>> >>> This vote is open for 72 hours and will pass unless getting a net >>> negative vote count. All votes are welcome and we encourage everyone, >>> but only the Logging Services PMC votes are officially counted. At >>> least 3 +1 votes and more positive than negative votes are required. >>> >>> [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q >>> [2] https://logging.apache.org/dormant.html >>> [3] https://github.com/apache/chainsaw
Re: Refining product feature set strategy
I see your point and agree with many things. I suggest we are not (only) making "data-driven" decisions. Most of us do this for fun, not for money. It is perfectly OK to decide just because we like it and enjoy ourselves. You are raising an excellent point: maintenance. We have a lot of stuff that appears to be less maintained, and it is impossible to judge if it is safe to use. We can always add new groups of components, similar to Apache Commons: Maintained, Sandbox, and Dormant, if moving to GitHub is not an option. I would categorize it like this: * Maintained: active contributions, three people willing to vote on releases and follow its development * Sandbox: active contributions, at least one person willing to keep an oversight, no releases necessary, website flagged with "This component is experimental - use at own risk." * Dormant: No active contributions, no (more) releases, website flagged with "This component is not maintained." While we don't need to take my proposal, I would like to implement something like this so: * we can keep a better oversight, * have a more clear communication with our users and * also have a clear guideline that saves us tons of "deprecation discussions." Kind regards, Christian On Fri, Sep 29, 2023, at 09:59, Volkan Yazıcı wrote: > I want to challenge the current way of PMC determining the product feature > set and work towards a more sustainable alternative. > > Logging Services team... > >- delivers mission-critical products that are deployed at the core of >the world-wide infrastructure (actually, in Mars too) >- is short on development resources compared to its wide range of >offerings >- deals with substantial amount of legacy >- suffers from knowledge silo > > Any IT team in this state would be really conservative on accepting new > features and try hard to get rid of the bloat. They would react to this > challenge by first discovering the user base, pinpointing the core values, > and then lazer-focusing the limited development resources on to the crucial > deliverables. Though we do something totally different, one can even say > the opposite. Below I share excerpts from recent mailing list posts. > > *"I had added [X] ... to show how to write plugins and for some > consulting-related use cases"* – PMC member explaining how feature X was > released > > *"... stuff seems like it could be useful"* – PMC member asking to keep > feature X > > *"my employer used [X] ... for anyone implementing ... this would be very > relevant. By archiving this we are basically telling users that they > cannot use it any more since it will no longer be supported. For that > reason I am not in favor of [retiring]"* – PMC member asking to keep > feature X > > *"We [the employer] ... use [X]"* – PMC member asking to keep feature X > > *"User base [is] ... very low to non-existent."* – PMC member asking to > keep product X > > *"[PMC member] has steadfastly [reacted] ... and until he positively says > he will no longer maintain it I am not willing to override that"* – PMC > member asking to keep product X because another (one and only) PMC member > reacted on product retirement inquiry > > *"Our employers are ... paying customers."* – a PMC member explaining why > we should keep feature X used by an organization employing another PMC > member > > > I see a pattern in the way we decide to maintain a feature/product: > >- It is not data-driven. It is disconnected from its user base. No usage >statistics, etc. is shared or used. >- We serve individuals' and employers' agendas. >- We underestimate the cost of adding/keeping a feature. > > I think this diet is "unhealthy" because: > >- It adds up to the bloat. It is yet another component developers need >to maintain its dependencies, documentation, website, integration with the >build system, etc. This bizarrely slows down the development experience. >(Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?) >- It adds up to the attack surface. >- Features that are supposed to be optional get shipped to users without >their consent. (Consider the percentage of the Log4Shell victims that used >the JNDI functionality at all.) >- Scarce development resources get wasted on chores due to the >excessive landscape. >- It gives users the wrong impression that the feature/product is >maintained, though under the hood it is just kept there because a >privileged group wants so. > > I want to refine this approach with your help. To start the discussion, I > propose the following strategy instead: > > *"We only accept a feature with data-driven justification."* – Have a brand > new idea? Grab yourself a GitHub/GitLab repository that belongs to either > you or your employer, knock yourself out without any ASF/PMC burdens, and > amaze your users. Once the user attraction gets enough gravity, let's > discuss blessing it as a part of
Re: [VOTE] Release Apache Log4j Kotlin API 1.3.0
+1 -- The Apache Software Foundation V.P., Data Privacy On Thu, Sep 28, 2023, at 15:26, Volkan Yazıcı wrote: > This is a vote to release the Apache Log4j Kotlin API 1.3.0. > > Source repository: https://github.com/apache/logging-log4j-kotlin > Commit: b273cfb450898f079d2fd10b575330bfb900101b > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1186 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 72 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. At least 3 +1 votes and more > positive than negative votes are required. > > === Release Notes > > This minor release bumps the Kotlin baseline to 1.6.21 and contains > various small improvements. > > Added > > * Added an extension property for storing a cached logger (#29) > * Added facade APIs for manipulating the context map and stack (#30) > * Added missing `catching` and `throwing` API methods in `KotlinLogger` (#32) > * Added JPMS support and used `org.apache.logging.log4j.api_kotlin` > for the module name (identical to OSGi `Bundle-SymbolicName`) of the > `log4j-api-kotlin` artifact > > Changed > > * Updated Log4j dependency to `2.20.0` > * Bumped `logging-parent` version to `10.1.0` and overhauled the > entire project infrastructure to take advantage of its goodies (#37) > * Renamed OSGi `Bundle-SymbolicName` from > `org.apache.logging.log4j.kotlin` to > `org.apache.logging.log4j.api_kotlin` > * Migrated tests to JUnit 5 > * Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4` > respectively
[VOTE] Release Apache Log4j Tools 0.5.0
This is a vote to release the Apache Log4j Tools 0.5.0. Source repository: https://github.com/apache/logging-log4j-tools Commit: 861b03c70a76ca19408ffc8c4a77bc0c4e5e4570 Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1187 Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 Please download, test, and cast your votes on this mailing list. [ ] +1, release the artifacts [ ] -1, don't release, because... This vote is open for 72 hours and will pass unless getting a net negative vote count. All votes are welcome and we encourage everyone to test the release, but only the Logging Services PMC votes are officially counted. At least 3 +1 votes and more positive than negative votes are required. === Release Notes This minor release contains various bug fixes and improvements. Added * Started publishing the project website[1] [1] https://logging.staged.apache.org/log4j/tools Changed * Made `author` element optional and bumped the XML schema version to `0.1.2` (#81) * Make `log4j-changelog-maven-plugin` thread-safe (#80) * Update `org.apache.logging:logging-parent` to version `10.1.0` (#82) * Update `org.junit.jupiter:junit-jupiter-engine` to version `5.10.0`
Refining product feature set strategy
I want to challenge the current way of PMC determining the product feature set and work towards a more sustainable alternative. Logging Services team... - delivers mission-critical products that are deployed at the core of the world-wide infrastructure (actually, in Mars too) - is short on development resources compared to its wide range of offerings - deals with substantial amount of legacy - suffers from knowledge silo Any IT team in this state would be really conservative on accepting new features and try hard to get rid of the bloat. They would react to this challenge by first discovering the user base, pinpointing the core values, and then lazer-focusing the limited development resources on to the crucial deliverables. Though we do something totally different, one can even say the opposite. Below I share excerpts from recent mailing list posts. *"I had added [X] ... to show how to write plugins and for some consulting-related use cases"* – PMC member explaining how feature X was released *"... stuff seems like it could be useful"* – PMC member asking to keep feature X *"my employer used [X] ... for anyone implementing ... this would be very relevant. By archiving this we are basically telling users that they cannot use it any more since it will no longer be supported. For that reason I am not in favor of [retiring]"* – PMC member asking to keep feature X *"We [the employer] ... use [X]"* – PMC member asking to keep feature X *"User base [is] ... very low to non-existent."* – PMC member asking to keep product X *"[PMC member] has steadfastly [reacted] ... and until he positively says he will no longer maintain it I am not willing to override that"* – PMC member asking to keep product X because another (one and only) PMC member reacted on product retirement inquiry *"Our employers are ... paying customers."* – a PMC member explaining why we should keep feature X used by an organization employing another PMC member I see a pattern in the way we decide to maintain a feature/product: - It is not data-driven. It is disconnected from its user base. No usage statistics, etc. is shared or used. - We serve individuals' and employers' agendas. - We underestimate the cost of adding/keeping a feature. I think this diet is "unhealthy" because: - It adds up to the bloat. It is yet another component developers need to maintain its dependencies, documentation, website, integration with the build system, etc. This bizarrely slows down the development experience. (Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?) - It adds up to the attack surface. - Features that are supposed to be optional get shipped to users without their consent. (Consider the percentage of the Log4Shell victims that used the JNDI functionality at all.) - Scarce development resources get wasted on chores due to the excessive landscape. - It gives users the wrong impression that the feature/product is maintained, though under the hood it is just kept there because a privileged group wants so. I want to refine this approach with your help. To start the discussion, I propose the following strategy instead: *"We only accept a feature with data-driven justification."* – Have a brand new idea? Grab yourself a GitHub/GitLab repository that belongs to either you or your employer, knock yourself out without any ASF/PMC burdens, and amaze your users. Once the user attraction gets enough gravity, let's discuss blessing it as a part of the official Logging Services offering. Official support channels are always open to assist the developers of such external efforts. *"We only keep a feature with data-driven justification."* – Do you think a feature needs to be retired? Bring it up for discussion. PMC should evaluate the request based on numbers and this process should be independent of the individuals'/employers' agendas. If PMC decides to retire a feature/product *and* there are people who volunteer to continue the development on a successor fork outside of ASF, PMC should do their due diligence to point existing users to this fork without any endorsement. I look forward to hearing your thoughts.
