I am not proposing to implement this right now. All I am after is an agreement. Indeed we should pursue this route once staging is back to normal.
On Mon, Oct 23, 2023 at 2:05 AM 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. > >> >
