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

Reply via email to