I see a lot of arguments here that I would have liked to see on the discussion thread. Let's go back to that. BTW I disagree with most of them but they do need addressing in a discussion and keeping the voting thread open does not make sense. I don't care about political correctness one bit, but I do care about inclusivity if it aims to not scare away potential good developers. <politics mode=incorrect> I really think all those arguments against are excrements of male cattle. </politics> Please, all bring your arguments to the discussion thread, https://markmail.org/message/k767evgjnmzogyhf .
On Fri, Apr 30, 2021 at 11:28 PM Andrija Panic <andrija.pa...@gmail.com> wrote: > -1 (non-binding) > (even though I'm a PMC member - I believe I have the right to cast a > non-binding vote? Otherwise I would change it to 0) > > > Explanation: > > While I do know where this comes from, and while my following comment has > NOTHING to do with the person who raised it (my own colleague who I > appreciate very much), I have to state my "no -opinion" for this vote/topic > in general: > > > 1. What is offensive with the word "master" - shall we ask it's removed > from the dictionary as well?, shall we ask words like "slave", "black", > "white" and other extremes to be removed? Shall we remove words male / > female (or even HE/SHE let it just be IT) so that everyone is unisex and > shall we change...let's change the whole world... > > 2. This whole movement (in wild) is the absolute political bullshit > (apologies for sharp tongue), utter nonsense which will make nobody's life > better, or make "slaved" people more free, or will allow people in many > countries to have a free walk (during this "pandemic" times), etc, etc. > Real-life (outside of computer) freedoms are DRASTICALLY cut down, against > all laws and constitution in many countries, but we are changing branch > names, renaming "master" to "main" (for the record, I might find the word > "main" offending to me, so I might raise another vote for something even > more neutral...) and making some changes which change nothing for anyone. > > Removing "master" and "slave" will not erase the history, which was... what > it was...ugly and full of blood and misery for some. And history, should > not be forgotten - because we learn from it about bad things in order for > them to NOT happen again. > > //political uncoretness off > //rant off > peace to the world > > > > On Fri, 30 Apr 2021 at 17:53, 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 > > > > > > > > > > > > > > > > > -- > > Andrija Panić > -- Daan
