Re: [chainsaw] Status change?

[Ralph Goers]

If Scott is +1 then let’s start a vote thread for this.

Ralph

> On Feb 7, 2024, at 8:56 AM, Robert Middleton  wrote:
> 
> +1
> 
> While I agree that it can be useful, it was never really in a state
> where it is.  I think it has a lot of good ideas, but to make it more
> modern and practical it needs to have a much better workflow.
> 
> I may mess around with it more at some point, but it would take a lot
> to be practical.
> 
> If there is a concerted effort in the future to improve it by people
> who do find it useful, I would definitely be open to looking at it
> again.
> 
> -Robert Middleton
> 
> On Wed, Feb 7, 2024 at 2:56 AM Volkan Yazıcı  wrote:
>> 
>> +1
>> 
>> Allow me to make some corrections:
>> 
>> `XmlLayout` is dropped in Log4j 3, not in Log4j 2.
>> 
>> Logstash (the L in the ELK, Elasticsearch-Logstash-Kibana, stack) supports
>> reading logs from a file formatted using a particular pattern. You combine
>> Filebeat with grok filter
>> 
>> to achieve that.
>> 
>> 
>> On Wed, Feb 7, 2024 at 5:19 AM Scott Deboy  wrote:
>> 
>>> Thank you for spending time working on it Christian.
>>> 
>>> I started contributing to Chainsaw in 2003. I agree. It's time.
>>> 
>>> The primary benefit of Chainsaw was its built-in support for real-time
>>> tailing of ssh-accessible pattern-layout based logs  - something
>>> Kibana doesn't support well, and something no-one ever really
>>> understood about it.
>>> 
>>> It was always a dev-focused tool - it works great for local dev, and
>>> works in some prod envs, if you spend enough time to get the setup to
>>> work.
>>> 
>>> There was no great reason to move off of the log41 deps really - they
>>> aren't used for anything other than parsing the patternlayout, but
>>> log4j1 is dead, so I get it.
>>> 
>>> I use it for my work, and will continue to do so, but the
>>> chainsaw-with-log4j1-dep branch. I may revert master back to that,
>>> because why not.
>>> 
>>> +1
>>> 
>>> Thanks again for putting up with my persistence to try and make it
>>> useful to folks - I appreciate it  :)
>>> 
>>> Scott
>>> 
>>> 
>>> On 2/6/24, Christian Grobmeier  wrote:
 Hello
 
 we have had Chainsaw for a long time in our product list, and I can
>>> totally
 see that some - myself included - are emotionally attached to it.
>>> However,
 due to my work on it, I have given it some additional thought.
 
 After working with the Chainsaw code base for a while, I saw that many
 features were commented out and removed when migrating to Log4j 2.
 
 Some basic features, such as "Open Logfile to view it directly." were
 removed. It is already hard to recover the functionality since
>>> log4j-extras
 no longer exists. In addition, as I learned recently, Log4j 2 has removed
 the XML Formatter. The old implementation of Chainsaw could only open
 XML-formatted log files.
 
 Honestly, there is much work to make Chainsaw a working product again. I
 mostly did refactorings and clean-ups, but I am not even through. I could
 continue like this for two more months.
 
 Restoring the old functionality and making it functional again requires
>>> even
 more months.
 If we had completed it, we would have restored a Swing application,
>>> mostly
 replaced by Kibana stacks.
 
 At this point, I don't see how we can write the tons of code necessary,
>>> and
 also not how useful it would be. Either all our users are using Log4j 1,
>>> or
 we don't have any users at all for Chainsaw, since it didn't work.
 
 For that reason, I would like to propose to move Chainsaw to dormant. If
>>> we
 feel for it, we can work and fix it - we should not archive the repo.
>>> But I
 would like to make clear that Chainsaw is not in good shape, and people
 should only use it only "at their own risk."
 
 I would like to make clear that this proposal is not something I say
>>> easily,
 but I feel it is in the best interest of our users to communicate how we
 currently see the status of this project.
 
 Please note, that I don't have much time to continue to work on it in the
 next months.
 
 Remembering the last discussion about this: Scott, are you OK with that
 move? I know it's your baby, but as long as we don't have a working
>>> product,
 we should move it. I am open to moving it back when we somehow get rid of
 all the problems.
 
 Please let me know if one of you has an alternate proposal - we can also
 discuss it in the next call.
 
 Kind regards,
 Christian
 
 --
 The Apache Software Foundation
 V.P., Data Privacy
 
>>> 

Re: [chainsaw] Status change?

[Robert Middleton]

+1

While I agree that it can be useful, it was never really in a state
where it is.  I think it has a lot of good ideas, but to make it more
modern and practical it needs to have a much better workflow.

I may mess around with it more at some point, but it would take a lot
to be practical.

If there is a concerted effort in the future to improve it by people
who do find it useful, I would definitely be open to looking at it
again.

-Robert Middleton

On Wed, Feb 7, 2024 at 2:56 AM Volkan Yazıcı  wrote:
>
> +1
>
> Allow me to make some corrections:
>
> `XmlLayout` is dropped in Log4j 3, not in Log4j 2.
>
> Logstash (the L in the ELK, Elasticsearch-Logstash-Kibana, stack) supports
> reading logs from a file formatted using a particular pattern. You combine
> Filebeat with grok filter
> 
> to achieve that.
>
>
> On Wed, Feb 7, 2024 at 5:19 AM Scott Deboy  wrote:
>
> > Thank you for spending time working on it Christian.
> >
> > I started contributing to Chainsaw in 2003. I agree. It's time.
> >
> > The primary benefit of Chainsaw was its built-in support for real-time
> > tailing of ssh-accessible pattern-layout based logs  - something
> > Kibana doesn't support well, and something no-one ever really
> > understood about it.
> >
> > It was always a dev-focused tool - it works great for local dev, and
> > works in some prod envs, if you spend enough time to get the setup to
> > work.
> >
> > There was no great reason to move off of the log41 deps really - they
> > aren't used for anything other than parsing the patternlayout, but
> > log4j1 is dead, so I get it.
> >
> > I use it for my work, and will continue to do so, but the
> > chainsaw-with-log4j1-dep branch. I may revert master back to that,
> > because why not.
> >
> > +1
> >
> > Thanks again for putting up with my persistence to try and make it
> > useful to folks - I appreciate it  :)
> >
> > Scott
> >
> >
> > On 2/6/24, Christian Grobmeier  wrote:
> > > Hello
> > >
> > > we have had Chainsaw for a long time in our product list, and I can
> > totally
> > > see that some - myself included - are emotionally attached to it.
> > However,
> > > due to my work on it, I have given it some additional thought.
> > >
> > > After working with the Chainsaw code base for a while, I saw that many
> > > features were commented out and removed when migrating to Log4j 2.
> > >
> > > Some basic features, such as "Open Logfile to view it directly." were
> > > removed. It is already hard to recover the functionality since
> > log4j-extras
> > > no longer exists. In addition, as I learned recently, Log4j 2 has removed
> > > the XML Formatter. The old implementation of Chainsaw could only open
> > > XML-formatted log files.
> > >
> > > Honestly, there is much work to make Chainsaw a working product again. I
> > > mostly did refactorings and clean-ups, but I am not even through. I could
> > > continue like this for two more months.
> > >
> > > Restoring the old functionality and making it functional again requires
> > even
> > > more months.
> > > If we had completed it, we would have restored a Swing application,
> > mostly
> > > replaced by Kibana stacks.
> > >
> > > At this point, I don't see how we can write the tons of code necessary,
> > and
> > > also not how useful it would be. Either all our users are using Log4j 1,
> > or
> > > we don't have any users at all for Chainsaw, since it didn't work.
> > >
> > > For that reason, I would like to propose to move Chainsaw to dormant. If
> > we
> > > feel for it, we can work and fix it - we should not archive the repo.
> > But I
> > > would like to make clear that Chainsaw is not in good shape, and people
> > > should only use it only "at their own risk."
> > >
> > > I would like to make clear that this proposal is not something I say
> > easily,
> > > but I feel it is in the best interest of our users to communicate how we
> > > currently see the status of this project.
> > >
> > > Please note, that I don't have much time to continue to work on it in the
> > > next months.
> > >
> > > Remembering the last discussion about this: Scott, are you OK with that
> > > move? I know it's your baby, but as long as we don't have a working
> > product,
> > > we should move it. I am open to moving it back when we somehow get rid of
> > > all the problems.
> > >
> > > Please let me know if one of you has an alternate proposal - we can also
> > > discuss it in the next call.
> > >
> > > Kind regards,
> > > Christian
> > >
> > > --
> > > The Apache Software Foundation
> > > V.P., Data Privacy
> > >
> >

Re: Clean site repo

[Robert Middleton]

FWIW I believe that keeping around old sites is useful, but only if
there's a banner that says "this is out of date, please use the newest
version" with a link to the new version.  The reason for keeping them
around is that  sometimes you are stuck on an older version, so you
need that archived documentation(since it is possible that some
behavior has changed between versions, and/or a newer API that you
want to use is not available with your version).

-Robert Middleton

On Wed, Feb 7, 2024 at 5:29 AM Piotr P. Karwasz  wrote:
>
> Hi Volkan,
>
> On Wed, 7 Feb 2024 at 11:05, Volkan Yazıcı  wrote:
> > I can see the use cases for wanting to keep the website+manual of every
> > single release in a dedicated directory. Though my counter arguments are:
> >
> >1. These pages were never officially linked, hence were not exposed to
> >users. What is the pressing need right now to make this happen?
> >2. They get search engines confused and cause users to end up in legacy
> >pages.
> >3. The infrastructure to realize this (putting each release to a
> >separate site branch) is cumbersome, difficult to navigate for 
> > developers,
> >deviates from the standard the rest of our websites follow, and hence
> >complicates the release process substantially.
> >4. We (almost) never break backward compatibility in a major release
> >line. Hence, the docs of `2.x` is a superset of the docs of, say, 
> > `2.22.0`.
> >We also always document newly added features as "Starting from version
> >`2.22.0`, ..." Given these, I don't see a compelling point of having a
> >separate website for `2.22.0`.
>
> I might add that documentation is never bug-free and I consider the
> documentation of a release as important as the release itself.
>
> Since the only maintained releases are 2.22.x and 3.x (and perhaps
> 2.3.x and 2.12.x for security updates), I don't see a reason to
> publish the documentation of anything else than those releases.
>
> BTW: we should add a banner to the 1.x, extras, 2.3.x and 2.12.x
> websites that states that they refer to archived software that reached
> EOL.
>
> Piotr

Re: Clean site repo

[Piotr P. Karwasz]

Hi Volkan,

On Wed, 7 Feb 2024 at 11:05, Volkan Yazıcı  wrote:
> I can see the use cases for wanting to keep the website+manual of every
> single release in a dedicated directory. Though my counter arguments are:
>
>1. These pages were never officially linked, hence were not exposed to
>users. What is the pressing need right now to make this happen?
>2. They get search engines confused and cause users to end up in legacy
>pages.
>3. The infrastructure to realize this (putting each release to a
>separate site branch) is cumbersome, difficult to navigate for developers,
>deviates from the standard the rest of our websites follow, and hence
>complicates the release process substantially.
>4. We (almost) never break backward compatibility in a major release
>line. Hence, the docs of `2.x` is a superset of the docs of, say, `2.22.0`.
>We also always document newly added features as "Starting from version
>`2.22.0`, ..." Given these, I don't see a compelling point of having a
>separate website for `2.22.0`.

I might add that documentation is never bug-free and I consider the
documentation of a release as important as the release itself.

Since the only maintained releases are 2.22.x and 3.x (and perhaps
2.3.x and 2.12.x for security updates), I don't see a reason to
publish the documentation of anything else than those releases.

BTW: we should add a banner to the 1.x, extras, 2.3.x and 2.12.x
websites that states that they refer to archived software that reached
EOL.

Piotr

Re: Clean site repo

[Volkan Yazıcı]

On Tue, Feb 6, 2024 at 5:46 PM Ralph Goers 
wrote:

> When you say “hard to work with it” what does that mean?


Git commands work slow (e.g., `git status` takes seconds) and it is
difficult to understand what goes where.


> Volkan has mentioned some ideas to me which would allow us to keep the
> relevant info from previous releases.
>

> I don’t like the idea of having multiple efforts going on.
>

Piotr implements the `1.x`, `2.x`, `3.x` scheme I proposed earlier. Though
I still think Log4j 1, Log4j 2, and Log4j 3 websites should be moved to the
`logging-log4j2` repository and `logging-log4j-site` repository should only
be used for stuff that doesn't belong to a particular project repository,
e.g., `log4j-extras` (since the original `log4j-extras` repository is
converted to be read-only, we cannot move its website there) and
`/xml/ns/changelog`. Nevertheless, Piotr's proposal can be a good first
step in the direction I proposed earlier.

Regarding keeping the website+manual of the old releases (e.g.,
`/log4j/log4j-2.19.0`, `/log4j/log4j-2.20.0`) without ending up in a state
which we currently are... This is doable. We can place, say, `log4j-2.22.1`
folder to a `asf-site-log4j-2.22.1` branch with its own `.asf.yaml`
targeting the output to `/log4j/log4j-2.22.1`. Though... should we?

I can see the use cases for wanting to keep the website+manual of every
single release in a dedicated directory. Though my counter arguments are:

   1. These pages were never officially linked, hence were not exposed to
   users. What is the pressing need right now to make this happen?
   2. They get search engines confused and cause users to end up in legacy
   pages.
   3. The infrastructure to realize this (putting each release to a
   separate site branch) is cumbersome, difficult to navigate for developers,
   deviates from the standard the rest of our websites follow, and hence
   complicates the release process substantially.
   4. We (almost) never break backward compatibility in a major release
   line. Hence, the docs of `2.x` is a superset of the docs of, say, `2.22.0`.
   We also always document newly added features as "Starting from version
   `2.22.0`, ..." Given these, I don't see a compelling point of having a
   separate website for `2.22.0`.

In short,

   1. Release-specific website+manual (i.e., `/log4j/log4j-2.19.0`) was
   never an official service
   2. It is difficult to implement and wrap automation around it
   3. We can postpone it to a time where a need arises

Re: Clean site repo

[Volkan Yazıcı]

+1

Nit: I would use `2.3.x` and `2.12.x` to match the `.x` suffix convention
we use in `1.x`, `2.x`, and `3.x`. Or totally the other way around, no `.x`
suffix at all: `1`,  `2`, `2.3`, `2.12`, and `3`.

On Tue, Feb 6, 2024 at 5:06 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> The current `asf-site` branch of the `logging-log4j-site` repo has
> about 450k files, which makes it very hard to work on it.
>
> Most of those are websites of old releases that I doubt anybody
> (except search engines) visits. Those websites also pollute search
> engine results: several times I found the page of an old release
> better ranked that the current version.
>
> Therefore I created a new branch `clean-log4j`[1] (which is published
> as [2]) that contains only these directories:
>
> * 1.x: last 1.x release.
> * 2.3: last 2.3 release. Although not strictly necessary, I thought
> that people stuck with Java 6 will appreciate a website without all
> the features from newer releases.
> * 2.12: last 2.12 release.
> * 2.x: latest 2.x release.
> * 3.x: latest 3.x release.
> * extras: last Apache Log4j Extras release.
>
> and the XML schemata for our changelog format (although they should be
> moved to `/xml/ns/changelog`).
>
> All the `log4j-` and similar directories are redirected
> (permanent 301 redirect) to one of the remaining one: e.g.
> `log4j-2.0.1` is redirected to `2.3`, `log4j-2.4` is redirected to
> `2.12`, while `2.13.0` (sic!) is redirected to `2.x`.
>
> For those that like to go down memory lane, the branch contains 65
> commits for each one of our releases.
>
> What do you think about replacing `asf-site` with this branch?
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j-site/tree/clean-staging
> [2] https://logging-clean.staged.apache.org/log4j
>