Retire Chainsaw
AFAIC, Chainsaw is hardly getting any maintenance. Considering its activity over the years, I haven't witnessed a user base either. I suppose the trend in processing logs (i.e., rendering them into JSON and storing them in Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from `PatternLayout`-rendered files collected under `/var/logs`. I would like to retire[1] Chainsaw in a vote thread. Thoughts? [1] Retirement translates to archival of the repository and clearing up its mentions in `logging.apache.org`.
Re: Retire Chainsaw
> Chainsaw is hardly getting any maintenance It is sad the PMC rejects CVE fixes. >> [1] Retirement translates to archival of the repository and clearing up its > mentions in `logging.apache.org`. It sounds awful to "deprecate and remove references" simultaneously. How should users know something is deprecated if you do not announce it previously? Any deprecation should leave a 5-10-year window before removal. There might be active users, so keeping the documentation on the website would be great even if the software is no longer maintained. I believe nobody would complain, however, if you remove the documentation from the site, people would have to resort to a Wayback machine and things like that. Vladimir
Re: Retire Chainsaw
Well, it still works well, and real time log analysis and Chainsaw's support for filtering are very powerful for many dev-local use cases. User base I can't speak to, but I agree based on lack of questions it's probably very low to non-existent. I'd prefer we find an option that isn't "nuke it from orbit". Scott On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı wrote: > AFAIC, Chainsaw is hardly getting any maintenance. Considering its activity > over the years, I haven't witnessed a user base either. I suppose the trend > in processing logs (i.e., rendering them into JSON and storing them in > Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from > `PatternLayout`-rendered files collected under `/var/logs`. I would like to > retire[1] Chainsaw in a vote thread. Thoughts? > > [1] Retirement translates to archival of the repository and clearing up its > mentions in `logging.apache.org`. >
Re: Retire Chainsaw
I think I agree with Scott: I don't see a reason to nuke it. We can't really tell what usage looks like. WRT 5-10 years... uh? Where would those numbers come from? I'd never commit to anything in that time frame outside of a commercial support contract. Gary On Tue, Sep 19, 2023, 6:26 AM Scott Deboy wrote: > Well, it still works well, and real time log analysis and Chainsaw's > support for filtering are very powerful for many dev-local use cases. > > User base I can't speak to, but I agree based on lack of questions it's > probably very low to non-existent. > > I'd prefer we find an option that isn't "nuke it from orbit". > > Scott > > > > On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı wrote: > > > AFAIC, Chainsaw is hardly getting any maintenance. Considering its > activity > > over the years, I haven't witnessed a user base either. I suppose the > trend > > in processing logs (i.e., rendering them into JSON and storing them in > > Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from > > `PatternLayout`-rendered files collected under `/var/logs`. I would like > to > > retire[1] Chainsaw in a vote thread. Thoughts? > > > > [1] Retirement translates to archival of the repository and clearing up > its > > mentions in `logging.apache.org`. > > >
Re: Retire Chainsaw
>> WRT 5-10 years... uh? Where would those numbers come from? I mean "at least 5-10 years". It costs virtually nothing, so why touch it? >to anything in that time frame outside of a commercial support contract. How much money do you need to "not remove chainsaw" from the webpage? As of now, it looks like keeping chainsaw website requires exactly zero maintenance, so I truly do not understand why you ask for a commercial contract. Vladimir
Re: Retire Chainsaw
The difference is between saying nothing (what we do now) and committing to future work (support for 5-10 years and then make it go away). Gary On Tue, Sep 19, 2023, 10:06 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >> WRT 5-10 years... uh? Where would those numbers come from? > > I mean "at least 5-10 years". It costs virtually nothing, so why touch it? > > >to anything in that time frame outside of a commercial support contract. > > How much money do you need to "not remove chainsaw" from the webpage? > As of now, it looks like keeping chainsaw website requires exactly > zero maintenance, > so I truly do not understand why you ask for a commercial contract. > > Vladimir >
Re: Retire Chainsaw
> The difference is between saying nothing (what we do now) and committing to > future work (support for 5-10 years and then make it go away). I am afraid I do not understand it. Could you explain it in more words? What is exactly the difference? Currently, it looks like the cost of "not removing a link from website" is zero. Of course, it might be something would require to update the site (js vulnerability in the generated website?) If that happens, it would be fair to bring the discussion of "updating jqery would take X hours while dropping the website would require Y hours, and X >> Y". We need to see X and Y before we discuss if "paid contract" is needed. Vladimir
Re: Retire Chainsaw
Scott, Apparently Chainsaw has dependencies that have CVEs reported against them (or so I am told). We haven’t enabled GitHub Issues for Chainsaw AFAIK. Both of these need to be addressed if the project is going to be considered active. Are you willing to help with both of these? Ralph > On Sep 19, 2023, at 3:25 AM, Scott Deboy wrote: > > Well, it still works well, and real time log analysis and Chainsaw's > support for filtering are very powerful for many dev-local use cases. > > User base I can't speak to, but I agree based on lack of questions it's > probably very low to non-existent. > > I'd prefer we find an option that isn't "nuke it from orbit". > > Scott > > > > On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı wrote: > >> AFAIC, Chainsaw is hardly getting any maintenance. Considering its activity >> over the years, I haven't witnessed a user base either. I suppose the trend >> in processing logs (i.e., rendering them into JSON and storing them in >> Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from >> `PatternLayout`-rendered files collected under `/var/logs`. I would like to >> retire[1] Chainsaw in a vote thread. Thoughts? >> >> [1] Retirement translates to archival of the repository and clearing up its >> mentions in `logging.apache.org`. >>
Re: Retire Chainsaw
An old colleague of mine said “Software decays over time”. This is a very true statement and applies to Chainsaw, just as it does to everything else. Java versions and dependencies become unsupported. Security bugs in dependencies get exposed. A project that just sits and never updates becomes untrustworthy due to all of these changing factors. The problems isn’t “not removing links”, it is that there is always a cost to saying something is still supported even if no one is doing any actual work on it. The longer the code goes untouched the longer that “future cost” becomes. Eventually someone has to do something. If no one ever is going to then you might as well let users know it is never going to be maintained. Ralph > On Sep 19, 2023, at 7:06 AM, Vladimir Sitnikov > wrote: > >>> WRT 5-10 years... uh? Where would those numbers come from? > > I mean "at least 5-10 years". It costs virtually nothing, so why touch it? > >> to anything in that time frame outside of a commercial support contract. > > How much money do you need to "not remove chainsaw" from the webpage? > As of now, it looks like keeping chainsaw website requires exactly > zero maintenance, > so I truly do not understand why you ask for a commercial contract. > > Vladimir
Re: Retire Chainsaw
Ralph, I already removed the socket appender vulnerability. I believe that was the only one. Scott On Tue, Sep 19, 2023, 11:10 AM Ralph Goers wrote: > Scott, > > Apparently Chainsaw has dependencies that have CVEs reported against them > (or so I am told). We haven’t enabled GitHub Issues for Chainsaw AFAIK. > Both of these need to be addressed if the project is going to be considered > active. Are you willing to help with both of these? > > Ralph > > > On Sep 19, 2023, at 3:25 AM, Scott Deboy wrote: > > > > Well, it still works well, and real time log analysis and Chainsaw's > > support for filtering are very powerful for many dev-local use cases. > > > > User base I can't speak to, but I agree based on lack of questions it's > > probably very low to non-existent. > > > > I'd prefer we find an option that isn't "nuke it from orbit". > > > > Scott > > > > > > > > On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı wrote: > > > >> AFAIC, Chainsaw is hardly getting any maintenance. Considering its > activity > >> over the years, I haven't witnessed a user base either. I suppose the > trend > >> in processing logs (i.e., rendering them into JSON and storing them in > >> Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from > >> `PatternLayout`-rendered files collected under `/var/logs`. I would > like to > >> retire[1] Chainsaw in a vote thread. Thoughts? > >> > >> [1] Retirement translates to archival of the repository and clearing up > its > >> mentions in `logging.apache.org`. > >> > >
Re: Retire Chainsaw
Scott, could you (or anybody else) spare time to perform the following maintenance tasks? 1. Update dependencies (e.g., `hsqldb:hsqldb:1.8.0.7` has a CVE) 2. Revamp the CI (preferably move it to GitHub Actions) 3. Migrate to GitHub Issues 4. Document the release process (unless it already exists) 5. Clean up the code base (e.g., `pom.xml` still refers to SVN) 6. Clean up the docs Otherwise, I agree with Ralph's points and I think it is better we communicate to our users that the project is not maintained anymore by means of archiving the repository. We can still keep links, docs, etc. around. If anybody later on steps up to maintain it and starts landing digestible, regular PRs, PMC can always decide to re-activate the archived repository. On Tue, Sep 19, 2023 at 8:27 PM Scott Deboy wrote: > Ralph, > > I already removed the socket appender vulnerability. I believe that was the > only one. > > Scott > > On Tue, Sep 19, 2023, 11:10 AM Ralph Goers > wrote: > > > Scott, > > > > Apparently Chainsaw has dependencies that have CVEs reported against them > > (or so I am told). We haven’t enabled GitHub Issues for Chainsaw AFAIK. > > Both of these need to be addressed if the project is going to be > considered > > active. Are you willing to help with both of these? > > > > Ralph > > > > > On Sep 19, 2023, at 3:25 AM, Scott Deboy > wrote: > > > > > > Well, it still works well, and real time log analysis and Chainsaw's > > > support for filtering are very powerful for many dev-local use cases. > > > > > > User base I can't speak to, but I agree based on lack of questions it's > > > probably very low to non-existent. > > > > > > I'd prefer we find an option that isn't "nuke it from orbit". > > > > > > Scott > > > > > > > > > > > > On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı wrote: > > > > > >> AFAIC, Chainsaw is hardly getting any maintenance. Considering its > > activity > > >> over the years, I haven't witnessed a user base either. I suppose the > > trend > > >> in processing logs (i.e., rendering them into JSON and storing them in > > >> Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from > > >> `PatternLayout`-rendered files collected under `/var/logs`. I would > > like to > > >> retire[1] Chainsaw in a vote thread. Thoughts? > > >> > > >> [1] Retirement translates to archival of the repository and clearing > up > > its > > >> mentions in `logging.apache.org`. > > >> > > > > >
Re: Retire Chainsaw
> The problems isn’t “not removing links”, it is that there is always a cost to > saying something is still supported even if no one is doing any actual work > on it. The longer the code goes untouched the longer that “future cost” > becomes. Eventually someone has to do something. If no one ever is going to > then you might as well let users know it is never going to be maintained. It is exactly the same thing I suggest: if the software is not going to receive new features, go ahead and mention that on the website (==mark it as deprecated). At the same time, keep the website afloat for 5-10 years after deprecation, so users can safely transition and/or refer to the documentation. I truly do not understand why PMC suggests "all or nothing". Either "chainsaw must be fully maintained" or "it must be nuked right away from the website". What is wrong with just adding "ok, this is no longer receiving attention because..." and keeping the website open for everybody in case they happen to run into chainsaw? Vladimir
Re: Retire Chainsaw
> Scott, could you (or anybody else) spare time to perform the following > maintenance tasks? I don't use chainsaw personally, however, I am afraid I might run into a project that does, so I would prefer to keep docs afloat. Volkan, Does the deal qualify for log4j 1.x? I would love to resolve issues like 1..6 for log4j 1.x: adding GitHub Actions CI, fixing stale pom references, documenting release steps, and so on. Vladimir
Re: Retire Chainsaw
The website should simply be moved to the 'dormant projects' section of the logging website: https://logging.apache.org/dormant.html I am +1 on archiving. The current state of master is 'mostly working' at this point, I have spent some time in the past few years trying to get it to be in a reasonable state but I haven't yet found a need where chainsaw is a good fit. I think there are some good ideas in there that can be fleshed out more, but it has been largely dormant for several years at this point. -Robert Middleton On Tue, Sep 19, 2023 at 2:52 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > Scott, could you (or anybody else) spare time to perform the following > > maintenance tasks? > > I don't use chainsaw personally, however, I am afraid I might run into > a project that does, so I would prefer to keep docs afloat. > > Volkan, > Does the deal qualify for log4j 1.x? > I would love to resolve issues like 1..6 for log4j 1.x: adding GitHub > Actions CI, fixing stale pom references, documenting release steps, > and so on. > > Vladimir >
Re: Retire Chainsaw
Scott, I think you misunderstood. I wasn’t referring to any CVEs in Chainsaw code but in dependencies Chainsaw uses. Users expect dependencies to be updated periodically so that they can build a project that passes all their security scans. Ralph > On Sep 19, 2023, at 11:26 AM, Scott Deboy wrote: > > Ralph, > > I already removed the socket appender vulnerability. I believe that was the > only one. > > Scott > > On Tue, Sep 19, 2023, 11:10 AM Ralph Goers > wrote: > >> Scott, >> >> Apparently Chainsaw has dependencies that have CVEs reported against them >> (or so I am told). We haven’t enabled GitHub Issues for Chainsaw AFAIK. >> Both of these need to be addressed if the project is going to be considered >> active. Are you willing to help with both of these? >> >> Ralph >> >>> On Sep 19, 2023, at 3:25 AM, Scott Deboy wrote: >>> >>> Well, it still works well, and real time log analysis and Chainsaw's >>> support for filtering are very powerful for many dev-local use cases. >>> >>> User base I can't speak to, but I agree based on lack of questions it's >>> probably very low to non-existent. >>> >>> I'd prefer we find an option that isn't "nuke it from orbit". >>> >>> Scott >>> >>> >>> >>> On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı wrote: >>> AFAIC, Chainsaw is hardly getting any maintenance. Considering its >> activity over the years, I haven't witnessed a user base either. I suppose the >> trend in processing logs (i.e., rendering them into JSON and storing them in Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from `PatternLayout`-rendered files collected under `/var/logs`. I would >> like to retire[1] Chainsaw in a vote thread. Thoughts? [1] Retirement translates to archival of the repository and clearing up >> its mentions in `logging.apache.org`. >> >>
Re: Retire Chainsaw
Ralph, I didn't misunderstand. Scott On Tue, Sep 19, 2023, 12:30 PM Ralph Goers wrote: > Scott, > > I think you misunderstood. I wasn’t referring to any CVEs in Chainsaw code > but in dependencies Chainsaw uses. Users expect dependencies to be updated > periodically so that they can build a project that passes all their > security scans. > > Ralph > > > On Sep 19, 2023, at 11:26 AM, Scott Deboy wrote: > > > > Ralph, > > > > I already removed the socket appender vulnerability. I believe that was > the > > only one. > > > > Scott > > > > On Tue, Sep 19, 2023, 11:10 AM Ralph Goers > > wrote: > > > >> Scott, > >> > >> Apparently Chainsaw has dependencies that have CVEs reported against > them > >> (or so I am told). We haven’t enabled GitHub Issues for Chainsaw AFAIK. > >> Both of these need to be addressed if the project is going to be > considered > >> active. Are you willing to help with both of these? > >> > >> Ralph > >> > >>> On Sep 19, 2023, at 3:25 AM, Scott Deboy > wrote: > >>> > >>> Well, it still works well, and real time log analysis and Chainsaw's > >>> support for filtering are very powerful for many dev-local use cases. > >>> > >>> User base I can't speak to, but I agree based on lack of questions it's > >>> probably very low to non-existent. > >>> > >>> I'd prefer we find an option that isn't "nuke it from orbit". > >>> > >>> Scott > >>> > >>> > >>> > >>> On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı wrote: > >>> > AFAIC, Chainsaw is hardly getting any maintenance. Considering its > >> activity > over the years, I haven't witnessed a user base either. I suppose the > >> trend > in processing logs (i.e., rendering them into JSON and storing them in > Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from > `PatternLayout`-rendered files collected under `/var/logs`. I would > >> like to > retire[1] Chainsaw in a vote thread. Thoughts? > > [1] Retirement translates to archival of the repository and clearing > up > >> its > mentions in `logging.apache.org`. > > >> > >> > >
Deterministic formatter
Hi, Right now our Spotless configuration just specifies the lines endings, forbids tabs and sorts the imports. If we want to apply some OpenRewrite rule to the codebase (e.g. migrate all string concatenations to parameterized logging or migrate JUnit4 to Junit5), we need a deterministic formatter to clean up the mess OpenRewrite leaves behind. On my personal projects I've bee playing with Google Java format[1] for some time and it basically corresponds to what we already use except: * it has a non-configurable indentation of 2 spaces. There is also a Palantir Java format[2], which is as far as I can tell also non-configurable (which is a feature, not a problem). Both have maintained Eclipse and IntelliJ plugins. On the other hand of the spectrum there is an Eclipse formatter, which is fully configurable and apparently has an IntelliJ plugin[3]. This is the one I used at my dayjob, but it lead to months of discussions, complains about the settings and a list of trick and tips on how to change the formatting with comments. We also had a minor problem with import sorting: * the formatter does not sort imports, so we used Spotless to do it. However Spotless and the Eclipse IDE use a different collation, which generated some conflicts. What do you think about enforcing a deterministic formatter on our code? Piotr [1] https://github.com/google/google-java-format [2] https://github.com/palantir/palantir-java-format [3] https://plugins.jetbrains.com/plugin/6546-adapter-for-eclipse-code-formatter
