Re: Migrating the landing page
On Sat, Sep 23, 2023, at 02:30, Apache wrote: > You have to be kidding me. I now need to use Docker to build the web > site? And that is somehow simpler? The actual build is then done by GitHub Actions. And yes, I consider it a lot simpler to run one docker command (I even have a shell script for this) to check and let actions do the rest. You can see it in action on the privacy website. > > Ralph > >> On Sep 22, 2023, at 2:03 PM, Christian Grobmeier >> wrote: >> >> >> >>> On Fri, Sep 22, 2023, at 22:08, Ralph Goers wrote: >>> Personally, I hate all these tools. I picked JBake simply because I >>> could figure out how to run it with a simple Maven command. >>> >>> I really don’t see how you can make it any simpler by changing the >>> tooling. If you look at the instructions they are all git commands >>> except for “mvn install”. >>> >>> The current web site supports markdown and asciidoc. >>> >>> I am not in favor of changing the tooling for the sake of changing the >>> tooling. I am in favor of changing the tooling if there is some major >>> tangible benefit. I have always wanted to use tooling that would let us >>> edit the pages in a GUI editor similar to like Wix or Squarespace do. I >>> despise having to write things in Markdown or Asiciidoc and then run a >>> tool so I can preview what it is going to look like. >>> >>> In other words, I want the ease of editing and maintaining the web site >>> to drive the tooling decision, not the other way around. >> >> Currently, there are 10 steps listed for deploying the website. >> I do "git commit && push" >> >> Currently, we have to install JBake >> In my scenario, I use Docker. >> >> As an example, for the privacy website to check: >> docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build >> --mount type=volume,dst=/root/build/node_modules -it >> apache/privacy_apache_org serve --watch --incremental >> >> There are significant benefits in this, such as speed of deployment, support >> of infra, etc pp. >> I don't see any reason to stick with JBake. >> >> I understand you don't like static site generators, but in this case, a less >> frequently updated website, I see benefits: easy blogging support and ASF >> support. Additionally, Docker support. >> >> There is also GUI support for Jekyll and Hugo, but I don't like it. There is >> none for JBake to my knowledge. >> >> I an not changing the tooling because I like Jekyll better, but because it >> is a standard, I have autodeploy tools ready and it generally is better >> understood than JBake. >> >> Kind regards, >> Christian >> >> >>> >>> Ralph >>> > On Sep 22, 2023, at 11:47 AM, Christian Grobmeier > wrote: Hello, the current landing page: https://logging.apache.org/ is done with JBake. We have rather complicated instructions on how to re-generate the landing page: https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites The Infra team recommends Pelican or Jekyll to create these kinds of pages. I have in-depth knowledge of Jekyll and would like to propose migrating the current landing page to Jekyll. The benefits: - autodeploy of our changes - great support of blogging (I'd like to create one) - easy handling and supported by Infra - writing content in Markdown I am aware that we have a discussion open on how to do documentation in the future. I would still like to migrate the page asap and - if deemed necessary - touch it again later. So far, I will leave all design/content intact until migrated, and come back with additional changes (as the blog) after migration to be discussed separately. If there are no objections, I will start with this move sometime next week. Thanks! Christian -- The Apache Software Foundation V.P., Data Privacy
Re: Migrating the landing page
Gentlemen, Im hoping we can get project chainsaw launched off at NASA on the coming months. If I can just keep my foot in the door there and maybe climb a few stairs, I think NASA might just want it ;-), but Im going to need a few weeks to see if we can get up those stairs. Nonetheless, I hope some contributions I could make might get it off the ground :-) Very much hope you all are doing well Cheers, -Rob > On Sep 23, 2023, at 7:47 AM, Christian Grobmeier wrote: > > > >> On Sat, Sep 23, 2023, at 02:30, Apache wrote: >> You have to be kidding me. I now need to use Docker to build the web >> site? And that is somehow simpler? > > The actual build is then done by GitHub Actions. And yes, I consider it a lot > simpler to run one docker command (I even have a shell script for this) to > check and let actions do the rest. > > You can see it in action on the privacy website. > >> >> Ralph >> On Sep 22, 2023, at 2:03 PM, Christian Grobmeier wrote: >>> >>> >>> On Fri, Sep 22, 2023, at 22:08, Ralph Goers wrote: Personally, I hate all these tools. I picked JBake simply because I could figure out how to run it with a simple Maven command. I really don’t see how you can make it any simpler by changing the tooling. If you look at the instructions they are all git commands except for “mvn install”. The current web site supports markdown and asciidoc. I am not in favor of changing the tooling for the sake of changing the tooling. I am in favor of changing the tooling if there is some major tangible benefit. I have always wanted to use tooling that would let us edit the pages in a GUI editor similar to like Wix or Squarespace do. I despise having to write things in Markdown or Asiciidoc and then run a tool so I can preview what it is going to look like. In other words, I want the ease of editing and maintaining the web site to drive the tooling decision, not the other way around. >>> >>> Currently, there are 10 steps listed for deploying the website. >>> I do "git commit && push" >>> >>> Currently, we have to install JBake >>> In my scenario, I use Docker. >>> >>> As an example, for the privacy website to check: >>> docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build >>> --mount type=volume,dst=/root/build/node_modules -it >>> apache/privacy_apache_org serve --watch --incremental >>> >>> There are significant benefits in this, such as speed of deployment, >>> support of infra, etc pp. >>> I don't see any reason to stick with JBake. >>> >>> I understand you don't like static site generators, but in this case, a >>> less frequently updated website, I see benefits: easy blogging support and >>> ASF support. Additionally, Docker support. >>> >>> There is also GUI support for Jekyll and Hugo, but I don't like it. There >>> is none for JBake to my knowledge. >>> >>> I an not changing the tooling because I like Jekyll better, but because it >>> is a standard, I have autodeploy tools ready and it generally is better >>> understood than JBake. >>> >>> Kind regards, >>> Christian >>> >>> Ralph >> On Sep 22, 2023, at 11:47 AM, Christian Grobmeier >> wrote: > > Hello, > > the current landing page: > https://logging.apache.org/ > > is done with JBake. We have rather complicated instructions on how to > re-generate the landing page: > https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites > > The Infra team recommends Pelican or Jekyll to create these kinds of > pages. I have in-depth knowledge of Jekyll and would like to propose > migrating the current landing page to Jekyll. > > The benefits: > > - autodeploy of our changes > - great support of blogging (I'd like to create one) > - easy handling and supported by Infra > - writing content in Markdown > > I am aware that we have a discussion open on how to do documentation in > the future. I would still like to migrate the page asap and - if deemed > necessary - touch it again later. > > So far, I will leave all design/content intact until migrated, and come > back with additional changes (as the blog) after migration to be > discussed separately. > > If there are no objections, I will start with this move sometime next > week. > > Thanks! > Christian > > -- > The Apache Software Foundation > V.P., Data Privacy
Re: Migrating the landing page
Rob, It looks like you are a PMC member of Commons as well as an ASF member. Given that, if you are interested in committing to and supporting Chainsaw I would happily vote to give you Logging Services commit privy. Ralph > On Sep 23, 2023, at 12:00 PM, Rob Tompkins wrote: > > Gentlemen, Im hoping we can get project chainsaw launched off at NASA on the > coming months. If I can just keep my foot in the door there and maybe climb a > few stairs, I think NASA might just want it ;-), but Im going to need a few > weeks to see if we can get up those stairs. > > Nonetheless, I hope some contributions I could make might get it off the > ground :-) > > Very much hope you all are doing well > > Cheers, > -Rob > >> On Sep 23, 2023, at 7:47 AM, Christian Grobmeier wrote: >> >> >> >>> On Sat, Sep 23, 2023, at 02:30, Apache wrote: >>> You have to be kidding me. I now need to use Docker to build the web >>> site? And that is somehow simpler? >> >> The actual build is then done by GitHub Actions. And yes, I consider it a >> lot simpler to run one docker command (I even have a shell script for this) >> to check and let actions do the rest. >> >> You can see it in action on the privacy website. >> >>> >>> Ralph >>> > On Sep 22, 2023, at 2:03 PM, Christian Grobmeier > wrote: > On Fri, Sep 22, 2023, at 22:08, Ralph Goers wrote: > Personally, I hate all these tools. I picked JBake simply because I > could figure out how to run it with a simple Maven command. > > I really don’t see how you can make it any simpler by changing the > tooling. If you look at the instructions they are all git commands > except for “mvn install”. > > The current web site supports markdown and asciidoc. > > I am not in favor of changing the tooling for the sake of changing the > tooling. I am in favor of changing the tooling if there is some major > tangible benefit. I have always wanted to use tooling that would let us > edit the pages in a GUI editor similar to like Wix or Squarespace do. I > despise having to write things in Markdown or Asiciidoc and then run a > tool so I can preview what it is going to look like. > > In other words, I want the ease of editing and maintaining the web site > to drive the tooling decision, not the other way around. Currently, there are 10 steps listed for deploying the website. I do "git commit && push" Currently, we have to install JBake In my scenario, I use Docker. As an example, for the privacy website to check: docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build --mount type=volume,dst=/root/build/node_modules -it apache/privacy_apache_org serve --watch --incremental There are significant benefits in this, such as speed of deployment, support of infra, etc pp. I don't see any reason to stick with JBake. I understand you don't like static site generators, but in this case, a less frequently updated website, I see benefits: easy blogging support and ASF support. Additionally, Docker support. There is also GUI support for Jekyll and Hugo, but I don't like it. There is none for JBake to my knowledge. I an not changing the tooling because I like Jekyll better, but because it is a standard, I have autodeploy tools ready and it generally is better understood than JBake. Kind regards, Christian > > Ralph > >>> On Sep 22, 2023, at 11:47 AM, Christian Grobmeier >>> wrote: >> >> Hello, >> >> the current landing page: >> https://logging.apache.org/ >> >> is done with JBake. We have rather complicated instructions on how to >> re-generate the landing page: >> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites >> >> The Infra team recommends Pelican or Jekyll to create these kinds of >> pages. I have in-depth knowledge of Jekyll and would like to propose >> migrating the current landing page to Jekyll. >> >> The benefits: >> >> - autodeploy of our changes >> - great support of blogging (I'd like to create one) >> - easy handling and supported by Infra >> - writing content in Markdown >> >> I am aware that we have a discussion open on how to do documentation in >> the future. I would still like to migrate the page asap and - if deemed >> necessary - touch it again later. >> >> So far, I will leave all design/content intact until migrated, and come >> back with additional changes (as the blog) after migration to be >> discussed separately. >> >> If there are no objections, I will start with this move sometime next >> week. >> >> Thanks! >> Christian >> >> -- >
Re: Migrating the landing page
Sound good…tell me where to start helping out. -Rob > On Sep 23, 2023, at 4:43 PM, Ralph Goers wrote: > > Rob, > > It looks like you are a PMC member of Commons as well as an ASF member. > Given that, if you are interested in committing to and supporting Chainsaw I > would happily vote to give you Logging Services commit privy. > > Ralph > > >> On Sep 23, 2023, at 12:00 PM, Rob Tompkins wrote: >> >> Gentlemen, Im hoping we can get project chainsaw launched off at NASA on the >> coming months. If I can just keep my foot in the door there and maybe climb >> a few stairs, I think NASA might just want it ;-), but Im going to need a >> few weeks to see if we can get up those stairs. >> >> Nonetheless, I hope some contributions I could make might get it off the >> ground :-) >> >> Very much hope you all are doing well >> >> Cheers, >> -Rob >> >>> On Sep 23, 2023, at 7:47 AM, Christian Grobmeier wrote: >>> >>> >>> On Sat, Sep 23, 2023, at 02:30, Apache wrote: You have to be kidding me. I now need to use Docker to build the web site? And that is somehow simpler? >>> >>> The actual build is then done by GitHub Actions. And yes, I consider it a >>> lot simpler to run one docker command (I even have a shell script for this) >>> to check and let actions do the rest. >>> >>> You can see it in action on the privacy website. >>> Ralph >> On Sep 22, 2023, at 2:03 PM, Christian Grobmeier >> wrote: > > > >> On Fri, Sep 22, 2023, at 22:08, Ralph Goers wrote: >> Personally, I hate all these tools. I picked JBake simply because I >> could figure out how to run it with a simple Maven command. >> >> I really don’t see how you can make it any simpler by changing the >> tooling. If you look at the instructions they are all git commands >> except for “mvn install”. >> >> The current web site supports markdown and asciidoc. >> >> I am not in favor of changing the tooling for the sake of changing the >> tooling. I am in favor of changing the tooling if there is some major >> tangible benefit. I have always wanted to use tooling that would let us >> edit the pages in a GUI editor similar to like Wix or Squarespace do. I >> despise having to write things in Markdown or Asiciidoc and then run a >> tool so I can preview what it is going to look like. >> >> In other words, I want the ease of editing and maintaining the web site >> to drive the tooling decision, not the other way around. > > Currently, there are 10 steps listed for deploying the website. > I do "git commit && push" > > Currently, we have to install JBake > In my scenario, I use Docker. > > As an example, for the privacy website to check: > docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build > --mount type=volume,dst=/root/build/node_modules -it > apache/privacy_apache_org serve --watch --incremental > > There are significant benefits in this, such as speed of deployment, > support of infra, etc pp. > I don't see any reason to stick with JBake. > > I understand you don't like static site generators, but in this case, a > less frequently updated website, I see benefits: easy blogging support > and ASF support. Additionally, Docker support. > > There is also GUI support for Jekyll and Hugo, but I don't like it. There > is none for JBake to my knowledge. > > I an not changing the tooling because I like Jekyll better, but because > it is a standard, I have autodeploy tools ready and it generally is > better understood than JBake. > > Kind regards, > Christian > > >> >> Ralph >> On Sep 22, 2023, at 11:47 AM, Christian Grobmeier wrote: >>> >>> Hello, >>> >>> the current landing page: >>> https://logging.apache.org/ >>> >>> is done with JBake. We have rather complicated instructions on how to >>> re-generate the landing page: >>> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites >>> >>> The Infra team recommends Pelican or Jekyll to create these kinds of >>> pages. I have in-depth knowledge of Jekyll and would like to propose >>> migrating the current landing page to Jekyll. >>> >>> The benefits: >>> >>> - autodeploy of our changes >>> - great support of blogging (I'd like to create one) >>> - easy handling and supported by Infra >>> - writing content in Markdown >>> >>> I am aware that we have a discussion open on how to do documentation in >>> the future. I would still like to migrate the page asap and - if >>> deemed necessary - touch it again later. >>> >>> So far, I will leave all design/content intact until migrated, and come >>> back with ad
[Chainsaw] Thoughts on moving forward
Since Scott has said that he would help with maintenance and Rob T has also indicated that he would perhaps help, this is my view of the current status of Chainsaw and what I feel its current deficiencies are. Current status: Master builds and mostly works. The last thing that I had been working on was updating the config files in order to remove xstream and better standardize on using commons configuration. I think some of the configuration settings don't save/load correctly, but some do. All of log4j1 has been removed. Certain features have been removed too that were largely dependent on log4j1. What I feel would be useful for Chainsaw: For me, I do a lot of embedded work. Most of the log files that we have at my current job just go to syslog on our device(syslog is provided by busybox). So viewing logs is a matter of SSHing into the system and just reading from the buffer. Having a utility running on a separate computer that lets me see the logs(especially if it can connect automatically to a device) could be very useful. Specific potential use-case: at my last job, I wrote a quick log viewing utility that would correlate log messages between two separate devices. This was needed because one device was embedded that logged out the serial port, the other was Linux and would log over the network, but neither had reliable time. Current limitations that I find with Chainsaw: The current GUI is not very useful. A large portion of the screen is taken up by toolbars/context information that I generally don't find useful. I think most of the features that are in the GUI are very useful(for example, being able to trace messages and add matches) but is limited by the fact that I only see a small portion of the context at a time. In my mind, an ideal solution would be to get rid of the toolbars as much as possible and to focus more on the log messages like you would see in a terminal, but still having the capability to right-click on a message/message components and investigate individual messages or flag them appropriately. Perhaps the best way to organize this would be to have a logical split in the code: the backend(which receives and routes log messages) and the front-end portion. The front-end could be something like Swing for a GUI, or some sort of command-line interface like ncurses. Thoughts? What is something that people want to see/think could be useful/would want to try and code up? -Robert Middleton
Re: [Chainsaw] Thoughts on moving forward
Please review the various display setting controls. Most of what you mention can be toggled from visible to hidden. VfsLogFilePatternReceiver does exactly what you're describing. Allowing live remote tailing of logs over an ssh accessible path. You control if these logs end up in separate tabs or the same tab via the routing expression in preferences. We should slack sometime so I can go over the main features and what was nuked in the log4j1 removal path and what of those are worth restoring. Scott On Sat, Sep 23, 2023, 6:08 PM Robert Middleton wrote: > Since Scott has said that he would help with maintenance and Rob T has also > indicated that he would perhaps help, this is my view of the current status > of Chainsaw and what I feel its current deficiencies are. > > Current status: Master builds and mostly works. The last thing that I had > been working on was updating the config files in order to remove xstream > and better standardize on using commons configuration. I think some of the > configuration settings don't save/load correctly, but some do. All of > log4j1 has been removed. Certain features have been removed too that were > largely dependent on log4j1. > > What I feel would be useful for Chainsaw: For me, I do a lot of embedded > work. Most of the log files that we have at my current job just go to > syslog on our device(syslog is provided by busybox). So viewing logs is a > matter of SSHing into the system and just reading from the buffer. Having > a utility running on a separate computer that lets me see the > logs(especially if it can connect automatically to a device) could be very > useful. Specific potential use-case: at my last job, I wrote a quick log > viewing utility that would correlate log messages between two separate > devices. This was needed because one device was embedded that logged out > the serial port, the other was Linux and would log over the network, but > neither had reliable time. > > Current limitations that I find with Chainsaw: The current GUI is not very > useful. A large portion of the screen is taken up by toolbars/context > information that I generally don't find useful. I think most of the > features that are in the GUI are very useful(for example, being able to > trace messages and add matches) but is limited by the fact that I only see > a small portion of the context at a time. In my mind, an ideal solution > would be to get rid of the toolbars as much as possible and to focus more > on the log messages like you would see in a terminal, but still having the > capability to right-click on a message/message components and investigate > individual messages or flag them appropriately. > > Perhaps the best way to organize this would be to have a logical split in > the code: the backend(which receives and routes log messages) and the > front-end portion. The front-end could be something like Swing for a GUI, > or some sort of command-line interface like ncurses. > > Thoughts? What is something that people want to see/think could be > useful/would want to try and code up? > > -Robert Middleton >
