I am -1 (i.e. - code commit veto) on any code change that causes the Log4j 2 web site url (https://logging.apache.org/log4j/2.x/) to no longer work. Since the staging site is a prelude to the live site I have to assume this change will cause the main site url to change so I am -1.
To be honest I am a little pissed. This all came about because Christian wanted to switch to Jekyll to which I have yet to understand any tangible benefit except he understands it better. The claim that It enables automatically pushing the site via CI is equally true for the current process. However, it will never be true for the Log4j web site since every release is located in its own subdirectory of the web site. As for dropping the -site repos I would need to see documentation on how I can have a window open in IntelliJ for the site vs the code. If all the IDEs support it then I would probably end up a +0 on it. To be honest I don’t see how git clone --bare g...@github.com <mailto:g...@github.com>:apache/logging-log4j2.git cd logging-log4j2.git git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" git worktree add ../logging-log4j2-2.x 2.x git worktree add ../logging-log4j2-main main git worktree add ../logging-log4j2-web-stg asf-staging git worktree add ../logging-log4j2-web-pro asf-site is simpler than git clone g...@github.com <mailto:g...@github.com>:apache/logging-log4j2.git 2.x git clone -b main g...@github.com <mailto:g...@github.com>:apache/logging-log4j2.git main git clone g...@github.com <mailto:g...@github.com>:apache/logging-log4j2-site.git Frankly I have no idea why you would want to have the working tree of asf-site. The only thing that should ever be done in the branch is a merge from asf-staging. I would also want to know how widespread doing this is. Will users get confused when we tell them they have to use a worktree? To be honest I’ve never used this before nor I have ever seen it used by anyone. That doesn’t mean it isn’t happening. As for closing the Nexus repo I always just used something like “Log4j 2.x.y-rc1”. I am not sure why this is all that important to standardize as long as it is clear what the release candidate is. IOW, I would be ok with your proposal but would also be ok with a policy that says the comment has to identify the rc version. Ralph > On Oct 19, 2023, at 1:03 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi, > > Since now we have a fast release process It might happen (and it > already did) that the voting periods for releases will not be > disjoint. > > That is why I would like to introduce a convention on the procedure to > stage websites and Nexus repositories. > > For websites I would propose: > > 1. Every Git code repository uses a different staging domain name. > E.g. `logging-log4j2` would set: > > staging: > profile: log4j2 > > which will result in a https://logging-log4j2.staged.apache.org URI. > For the `logging-log4j-site` website repo this will also entail that > it will have multiple staging branches. > 2. The `asf-staging` should not be protected. Before staging a website > the Release Manager would perform: > > git reset --hard origin/asf-site > git push -f > > hence ensuring that moving changes from the staging branch to > `asf-site` will be usually a fast-forward and a simple cherry-pick > `origin/asf-site..asf-staging` at worst. > > For the staging Nexus repo I would propose using a comment to close > the repo in the format: > > `<code-repo-name>` version `<version_number>` RC1 > > For example Volkan used "`logging-parent` version `10.2.0` RC`" on the > 1204 repo and we can easily guess what that repo contains. ;-) > > Piotr > > PS: Maybe we could drop the `*-site` Git repositories except > `logging-site` and move their content to an `asf-site/asf-staging` > branch of the corresponding code repo.
