+1 Fix the staging site. Defer talk about anything else until that is done.
Ralph > On Oct 22, 2023, at 5:05 PM, Christian Grobmeier <grobme...@apache.org> wrote: > > > >> On Sun, Oct 22, 2023, at 21:54, Volkan Yazıcı wrote: >> It has been a long thread and I want to capture the result: *there are no >> objections to Piotr's proposal, right?* If not, please say so. > > I am not objecting, but I would like to point out that logging.s.a.o is in > bad shape today, and I don't know why (in detail). I'd love to have this > working again before we move on to a different system. > If you know how to fix the system in a way that works with the original > proposal in one go, I am okay with it, too. However, I am afraid we are > touching too many wheels at once and navigating in a bad state. > > > >> >> To avoid misunderstanding, I want to repeat certain points one more time: >> >> 1. All existing logging.apache.org URLs will remain as is – no changes >> there. >> 2. Instead of using logging.*staged.*apache.org*/foo*, we will use >> logging*-foo.staged.*apache.org for staging websites. >> 3. Log4j Scala, Kotlin, Tools, and Transformation website content will >> be moved from `logging-log4j-site` repository to `logging-log4j-scala`, >> `logging-log4j-kotlin`, `logging-log4j-tools`, and >> `logging-log4j-transformation` repositories, respectively. >> >> >> On Thu, Oct 19, 2023 at 10: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. >>>
