Hi Ozone devs, I’d like to start a vote thread to change the default branch in the apache/ozone-site <https://github.com/apache/ozone-site> repo from asf-site to master. Changing the default branch requires an Infra ticket and mailing thread according to the asfyaml README <https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#default-branch>. I’ll start with some questions you may have when deciding to vote:
*Does this have anything to do with the new website development that is happening on the feature branch HDDS-9225-website-v2 <https://github.com/apache/ozone-site/tree/HDDS-9225-website-v2>?* No, this has nothing to do with the new website. The change would be effective for the existing website only since it concerns the asf-site and master branches, neither of which the new website uses right now. *What is the difference between asf-site and master?* The master branch contains the code that we modify and commit to change the website. The asf-site branch contains the already built website. The contents of asf-site are automatically generated from master and committed by a GitHub Action <https://github.com/apache/ozone-site/blob/master/.github/workflows/regenerate.yml>. >From there, existing ASF services read the .asf.yml <https://github.com/apache/ozone-site/blob/asf-site/.asf.yaml> file in the asf-site branch and copy the built contents from that branch to wherever the ASF is hosting the static sites for projects. *Why should we change the default branch from asf-site to master?* 1. (My primary motivation) Pull request templates only work if they are committed to the default branch <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates#pull-request-templates> . Committing the PR template from HDDS-10267 <https://issues.apache.org/jira/browse/HDDS-10267> to the asf-site branch would be clunky and difficult to modify. It is better to leave that branch for auto generated content only. That PR template currently does not work since it is not on the asf-site (current default) branch. 2. It’s confusing for users who go to the site on GitHub or clone the repo and expect to see the code they should modify to change the site. Instead they have to find the branch that actually has the code that the asf-site build content came from. 3. (Minor) PRs default to using the default branch. When filing a PR for the website, GitHub suggests using asf-site first, which gives a message stating that the changes cannot be merged since there is no common history. *Why is our current default asf-site?* I’m not sure, maybe someone in the community has historical context on this. It could be because this is the branch that pre-built docs are committed to when we copy them from the main Ozone repo (a practice we are looking to get rid of in the new website). It also seems there were some changes to branch publishing made around May 2021 <https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#publishing-a-branch-to-your-project-web-site> so perhaps it was required to be this way for publishing before those updates. *Is there any standard among other ASF projects for which branch should be the default?* I’ve looked at a bunch of other project’s websites and have yet to find one that’s using asf-site as the default. They are all using the development branch (equivalent to our master branch) as the default branch. See - https://github.com/apache/yunikorn-site - https://github.com/apache/streampipes-website - https://github.com/apache/kvrocks-website - https://github.com/apache/pulsar-site - https://github.com/apache/doris-website - https://github.com/apache/rocketmq-site *Will this affect the existing website?* This should not affect the existing website. The branch to use for deployment is hardcoded in .asf.yml <https://github.com/apache/ozone-site/blob/asf-site/.asf.yaml> and not implied from the repository’s default branch setting. Deployment should work as usual. I will double check with infra on the ticket to make sure no changes are required when making this change. Overall a long winded email for a pretty simple change. I’ll start with my +1 with the hope of incrementally improving the development experience of the current site, and in the future, the new website as well. Ethan
