Even though it wouldn't be of my preference, keeping both `staging` and `publish` configuration in `asf-site` sounds like a middle ground I can live with. I will appreciate it if you can adapt your existing changes (in `logging-log4j-kotlin`, `logging-parent`, etc.) to comply with this, unless you have already done so.
On Mon, Jan 15, 2024 at 12:27 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi Volkan, > > On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > * you can stage the website for a release with a simple: > > > > > > git checkout asf-staging > > > git reset --hard asf-site > > > unzip ... > > > git push -f > > > > > > > You can do the same in the existing setup too. You just need a `sed` > > one-liner to adapt the `.asf.yaml` content: > > > > $ sed -i -e 's/^publish:/staging:/g' -e 's/^ whoami:.+/ :whoami: > > asf-staging/g' asf.yaml > > > > Not to mention this is a detail that will be a part of the CI-based > release > > process. That is, no PMC member will need to recall or type any of these > > `git`, `sed`, `unzip`, etc. commands to cut a release. > > > > Given I addressed your "quickly stage a website" concern, are we good? > > I agree with your objections on not **requiring** all `.asf.yaml` to > be in sync. However I also don't see a reason not to have a `staging` > configuration on the `asf-site` branch and a `publish` configuration > on the `asf-staging` branch. > > I would prefer for the CI not to meddle with critical files such as > `.asf.yaml`, especially if changes to these files are almost never > required. > > Piotr > > PS: I removed the `publish` and `staging` sections on the main branch > of `logging-parent` and the `github` section on the site branches. >
