On Thu, Oct 19, 2023, at 19:38, Matt Sicker wrote: > If this is only for staging URLs and doesn’t break the production URLs, > this sounds reasonable.
+1 Actually, I would love to have staging sorted out first. Once it works as we are used to, I am open to anything. > > 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.
