Hi Volkan, On Mon, 15 Jan 2024 at 09:28, Volkan Yazıcı <vol...@yazi.ci> wrote: > Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"* > practice in `logging-parent` too. I find this new setup > > - *confusing* – Previously, say, `asf-site` related configuration was > only in the `asf-site` branch. Now it is in multiple branches of which > it has no association with. > - *requiring more work for changes* – If I need to make a change to > `asf-site`, I need to update in several branches. > - *prone to causing difficult to solve INFRA issues* – We know INFRA is > sensitive to configuration overrides that appear in multiple branches. > > Hence, I prefer you revert all these changes in all repositories and switch > back to *"configuration related to branch X goes to branch X"* practice.
This setup has some pros: * you don't need to navigate to all the website branches to see how they are configured, * you can stage the website for a release with a simple: git checkout asf-staging git reset --hard asf-site unzip ... git push -f I partly agree on your remark regarding INFRA issues: the INFRA script has problems with the **Github** configuration if we set it on multiple branches (the scripts run on the default branch, a branch named `main` and `master`). However I didn't notice any issues if you copy the **Website** configuration to multiple branches: the `whoami` parameter has been introduced exactly for that. INFRA ignores all website configuration unless `whoami` is equal to the name of the current branch. So maybe we could use a mixed approach: * the Github config can only be on a single branch, * the website config is copied to every branch. What do you think? See also my e-mail on the site repo/branches mess. I doubt most PMC members can tell you where each part of the website is coming from. Piotr