`worktree`s is a personal preference, I just shared how easy it would be to manage sources next to the website *using a single [git] clone*. Those who want to have multiple clones, can still do so. This has again nothing to do with Piotr's proposal. Piotr's proposal in essence is
1. generate single use domains *on staging* while voting a release 2. move the website of each project to the project's source code repository On Fri, Oct 20, 2023 at 7:55 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > 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 >
