If this is only for staging URLs and doesn’t break the production URLs, this sounds reasonable.
And the git worktree stuff is new to me! > On Oct 19, 2023, at 3: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.
