If the urls are preserved then I would not be -1. As far as the worktree stuff goes, I’d be in favor of that if it can be used to solve the issues Piotr mentions where Log4j-Scala and Log4j-Kotlin need to be independently committed and merged, although I have a suspicion that the ASF web site support would work better if those were in their own repos as I have my doubts they support worktrees.
Ralph > On Oct 19, 2023, at 4:37 PM, Christian Grobmeier <grobme...@apache.org> wrote: > > >>> Why are you pissed? I am sorry if I would be the reason >> >> 1. I indicated I didn’t want changing to Jekyl to be the reason for >> changing to Jekyll. So far, that appears to be the reason. I thought >> you mentioned something about getting CI to work but the current >> process could have been automated as well. > > No, that's not the reason. Switching to Jekyll would mean easy updates, data > files, SCSS support. > >> 2. Switching to Jekyll seems to have changed the target directory with >> dire consequences. As I stated, my experience with the ASF “CMS” is >> that you can “layer” web sites on top of each other by using sub-dirs >> of the content directory. I don’t recall the details as it has been >> several years since I migrated the web sites from the old CMS to the >> Git tooling provided by infra. But what I did was deliberate and on >> purpose. > > The output directory was changed. I took a lot of time (I am not used to > Python) to send 2 PRs to Infra: > https://github.com/apache/infrastructure-p6/pull/1704 > https://github.com/apache/infrastructure-p6/pull/1700 > To fix the output directory situation. > Both were accepted. The output directory is now working again, as described > in the docs. > https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features > > However, for unknown reasons, the webserver still does not recognize the fix. > That's why I asked for help and eventually created a ticket for Infra to help > return to the old status: > https://issues.apache.org/jira/browse/INFRA-25097 > >> 3. The final consequence is that it seems that we must now use >> logging-log4j2.staged.apache.org/log4j/2.x >> <http://logging-log4j2.staged.apache.org/log4j/2.x>. Since staging is >> supposed to exactly match live this means the live url now has to be >> logging-log4j2.apache.org/log4j/2.x >> <http://logging-log4j2.apache.org/log4j/2.x>. That is unacceptable. > > I agree this is unacceptable, but it is not the case that we must now use > this. > > I am working towards using the same system as before, using the same URLs > except, instead of jbake, with Jekyll. I am sorry that I ran into bugs I > could not control, but I am not enforcing or promoting a change of URLs just > because there are bugs. > > I want it to be "as before". Piotr's proposal contains ideas that have > nothing to do with my tooling change. You could decline it if you wish, > without any effect of the switch to Jekyll. > > To summarize: > > - I want to replace jbake with jekyll > - I don't want to change anything on the URLs > - I run into Infra bugs, that I fixed myself > - I now look at a web server mess, that I can't control, and wait for Infra > support > > Once Infra helps to sort out the webservers, it should be exactly as before. > > Again, I apologize for opening this discussion, it was not my intent. My > intent was to move to a tool that is easier to use (in my opinion), and that > helps me to promote log4j further. It is not the fault of the tooling that > the web server has that hiccup. > > I hope you are less pissed now, that you know that we are on the same page. > To be precise, I am pretty much stressed that the docs told me "it would > work" when I had to find out "it doesn't". > > Kind regards, > Christian
