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" <[email protected]> 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
    > 
    > 
    >  
    > 

Reply via email to