+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
>
>
>
>
