Hi Nathan, Appreciate your feedback on the PR(s). I've addressed your comments on these PR(s), please take a look.
On the other questions/comments you had, - Is there a overarching ASF criteria for what words are inappropriate for future development? => I am not aware of any criteria in ASF. I've contacted Gabriel on this, and he started a mail thread (at 'divers...@apache.org') here: https://lists.apache.org/thread.html/r0e076ffb20dbf80ee3e60c61f37cee69aa648c4860182ecfabb3abbf%40%3Cdiversity.apache.org%3E. Thanks Gabriel for initiating this discussion. If you are interested in further diversity discussions at Apache, subscribe to the mailing lists mentioned here: https://diversity.apache.org/. Recently, some words/terms are updated here: https://cwiki.apache.org/confluence/display/EDI/Nomenclature+alternatives. - Should there be git hooks similar to scan for such terms? => I think, No need of hooks for such terms. - How about when upstream projects use a inappropriate term? (for external / third party projects, MySQL, network interfaces) => the third party / dependency libraries, the terminologies used from external systems are excluded from this change. Regards, Suresh On 03/05/21, 10:54 AM, "Suresh Anaparti" <suresh.anapa...@shapeblue.com> wrote: Hi Nathan, Thanks for your feedback. I'll update the PR(s) as necessary. You can added your comments to the PR directly, so that these can be tracked and discussed there. Please note we'll go ahead with this rename change only after passing through the first step i.e. "Accepting all the CloudStack repo's (rename) PRs". Coming to the changes (over 5000 files) in repo "cloudstack-www", these are mainly the html pages in the apidocs with different CloudStack versions (may be unmaintained now, will check what can be done there). Regards, Suresh On 30/04/21, 9:23 PM, "Nathan McGarvey" <nathanmcgar...@gmail.com> wrote: +1, -1, and +0: Overall idea: +1 (Agree with Rene regarding context being important, too.) Some specific pull requests: -1 or 0: -1: How is this related? It seems to be a commit that shouldn't have been a part of this pull request since it is a brand new file that is unrelated: https://github.com/apache/cloudstack-www/pull/83/commits/9545ce619b377326daae5b303ffe89b5ea90a288 +0 or -1: I can't reasonably review this: https://github.com/apache/cloudstack-www/pull/83/commits/9ce732ceeb47bf6dee73073d892a51fbeea39f09 as it changed over 5000 files going back many many years in the past to now-dead/unmaintained code. This is a huge repo-bloat commit of doom. (You're changing API docs for dead code on something that can't even be manually reviewed). I'd suggest just adding an explanatory file for unsupported releases instead of changing thousands of files that are a decade old. Maybe even removing old API docs would be an option. Or just change the latest X releases, and gracefully age off the old ones. (Related: How much bigger does this make the git repo and how much longer does it take to apply diffs when cloning?) Other questions/comments: Is there a overarching ASF criteria for what words are inappropriate for future development? Should there be git hooks similar to scan for such terms? How about when upstream projects use a inappropriate term? E.g. MySQL pre-8.0.23 uses "master" in their configs, variables, and documents, but uses "replication source" or "replica", etc. after that point in time. (Ref: https://dev.mysql.com/doc/refman/8.0/en/binlog-replication-configuration-overview.html) Having a disjuncture between the implementation code and the upstream project makes it really hard to cross-reference documentation. The client/conf/db.properties.in file was changed to be db.cloud.backup, but why not make that db.cloud.replica or something that lines up with their documentation? Another example is with network interfaces. The "slave" term is different than the proposed "secondary" in Linux. A secondary interface actually means an alias or a fully separate physical device. Maybe "member device" or something is more correct. Thanks, -Nathan McGarvey On 4/30/21 6:43 AM, Suresh Anaparti wrote: > Hi All, > > Following the discussion thread on renaming default git branch name and inclusiveness [1], I would like to start a vote to gather consensus on the following plan: > > 1. Accept the following rename PRs (raised against 'master' branch) which renames git default branch to 'main' and replaces some offensive words, and Merge them post acceptance. > - cloudstack => PR: https://github.com/apache/cloudstack/pull/4922 > - cloudstack-documentation => PR: https://github.com/apache/cloudstack-documentation/pull/155 > - cloudstack-www => PR: https://github.com/apache/cloudstack-www/pull/83 > - cloudstack-cloudmonkey => PR: https://github.com/apache/cloudstack-cloudmonkey/pull/76 > - cloudstack-kubernetes-provider => PR: https://github.com/apache/cloudstack-kubernetes-provider/pull/29 > - cloudstack-ec2stack => PR: https://github.com/apache/cloudstack-ec2stack/pull/2 > - cloudstack-gcestack => PR: https://github.com/apache/cloudstack-gcestack/pull/3 > > 2. Request ASF infra to disable pushes to 'master' branch. > > 3. Rename 'master' branch to 'main' [2][3], and Request ASF infra (open INFRA ticket) to make 'main' as the default branch [4], in GitHub repo settings for all the CloudStack repos. This will also re-target the current PRs against 'master' branch to 'main'. > > 3a. The update on the central repo will be done as follows (only by a PMC or Infra member with access) > - Clone the repo (git clone https://github.com/apache/cloudstack.git) > - Sync local 'master' with the cloudstack repo (cd cloudstack && git checkout master && git fetch --all -p && git pull) > - Rename local 'master' branch to 'main' (git branch -m master main) > - Push renamed 'main' branch (git push -u origin main) > - Update Default Branch on GitHub [4] > - Delete 'master' branch (git push origin --delete master) > 3b. After the central renaming has been done. New users can clone and directly checkout 'main' branch. Existing users can start using 'main' locally, using the below steps. > - Switch to master branch (git checkout master) > - Rename local 'master' branch to 'main' (git branch -m master main) > - Sync local 'main' with repo (git fetch) > - Remove the existing tracking connection with “origin/master” (git branch --unset-upstream) > - Create a new tracking connection with the new “origin/main” branch (git branch -u origin/main) > - All local branches should still point to the same commit as base revision. If there is a problem (git checkout <problematic branch> && git rebase main) > > 4. Update the integrated systems with CloudStack repos, mainly Travis CI and Jenkins configuration with 'main' branch. Check and update UI building, apidocs, systemvmtemplate builds; project website and docs (cwiki); and any other build/release jobs. Track them through the issue: https://github.com/apache/cloudstack/issues/4887. > > 5. Perform Health Checks (using a dummy PR), and ensure there are no issues with the build/release configuration. This PR needs to run full matrix of tests. Fix the issues noticed during the health checks. > > 6. Announce the default branch change to 'main' (and 'master' deprecation) on the mailing list. > > The vote will be open until Fri 7th May 2021. > > For sanity in tallying the vote, Can PMC members please be sure to indicate “(binding)” with their vote? > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > [1] https://markmail.org/message/k767evgjnmzogyhf > [2] https://github.com/github/renaming > [3] https://docs.github.com/en/github/administering-a-repository/renaming-a-branch > [4] https://docs.github.com/en/github/administering-a-repository/changing-the-default-branch > > Regards, > Suresh > > > >
