You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@polaris.apache.org by "snazy (via GitHub)" <gi...@apache.org> on 2025/05/20 15:50:05 UTC
[PR] Site/contributing: add recommendations for working with PRs [polaris]
snazy opened a new pull request, #1625:
URL: https://github.com/apache/polaris/pull/1625
This change updates the PR guidelines on the "Contributing" web page after [this discussion](https://lists.apache.org/thread/kfxo3cqmw3pgrpgtgqvqpwvn46yw8q7h).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098458354
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
Seems like our repo is just not set up properly for this:
https://github.blog/changelog/2022-08-23-new-options-for-controlling-the-default-commit-message-when-merging-a-pull-request/
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2104286185
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
Review Comment:
It's also rather a tip. We had a few occurrences where PRs were in "ready for review" but were actually "work in progress" or "superseded" or "paused". Moved this to a separate "Tips" section.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098398025
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
The commit log of the main branch yes, but when you click `merge` on GitHub, you have the opportunity to create the commit message. By default, it takes it from the PR title & description.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098361539
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
> The Git commit subject and message will appear "as is" in release notes.
I think this isn't true, ideally it will be the PR title & description which go in release notes right? The rest of the statement is correct though
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098450073
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
I think your assumption is wrong. Compare #1572 with 9e6226aca61b9ff182d3174959274da6a038dca3
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2099797400
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
This is a different discussion that's out of scope of this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "keithgchapman (via GitHub)" <gi...@apache.org>.
keithgchapman commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2103188944
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
@eric-maynard We should create a separate issue for changing the repo setting and tackle it there. Thanks for bringing this up.
I went ahead and filed an [issue](https://github.com/apache/polaris/issues/1656) for this so that we don't forget.
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
Review Comment:
Would it make sense to update the sentence from
"Before opening a pull request, squash all commits in your branch into a single commit"
to
"Before opening a pull request, squash commits in your branch into a few (or single) meaningful commits"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on PR #1625:
URL: https://github.com/apache/polaris/pull/1625#issuecomment-2916851165
Hi @eric-maynard, the controversial sections in this PR have been addressed. Can you please take a look at them, review the changes, and reassess your -1
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098370951
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
No. It scans the commit log.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2103199598
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
Review Comment:
Do we need this rule? I'm not sure we discussed it on the thread and I'd like to minimize the number of rules a newcomer to the project has to follow.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2099982417
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
This change is not the right place to push for that change.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098367241
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
Review Comment:
Is this a best practice? When reviewing, I really dislike when people have done this because it makes it harder to see the changes since I last reviewed, or even the difference between two states of the change.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on PR #1625:
URL: https://github.com/apache/polaris/pull/1625#issuecomment-2917225097
Thx! Merged.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098458354
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
Seems like our repo is just not set up properly:
https://github.blog/changelog/2022-08-23-new-options-for-controlling-the-default-commit-message-when-merging-a-pull-request/
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098453442
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
Review Comment:
@eric-maynard this is to get to better messages. If you do it in another way but provide good PR + Git-merge-commit summary/description that's fine, too.
Also I don't understand your argument about reviews - again - this paragraph is about _*opening*_ the PR - there's nothing else you could review before, right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098399150
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
Review Comment:
My question stands, not sure how critical this step is. Smaller incremental commits is generally a good thing IMO.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098464466
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
I'm not sure why it is "not set up properly"? It's always been like this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on PR #1625:
URL: https://github.com/apache/polaris/pull/1625#issuecomment-2897525581
> Most changes LGTM, but some of the ideas here were not discussed in the mailing list and it seems that we may be able to [reconfigure the repo](https://github.blog/changelog/2022-08-23-new-options-for-controlling-the-default-commit-message-when-merging-a-pull-request/) to loosen some of the requirements around commit messages
The justification is missing concrete pointers. Also requesting _another_ change pushed into this change, which is clearly out of scope of this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2104281975
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
Review Comment:
It's meant as a "tip" - moved the controversial one to a separated "Tips" section.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2099966507
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
OK, but I think we should hold this change (on this PR) until we can try adjusting that setting.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098460971
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
Review Comment:
If this is to get better messages, then I'll just point to the other comment chain about using the PR description.
If this is about reviewability, I maintain that more commits is usually a good thing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "keithgchapman (via GitHub)" <gi...@apache.org>.
keithgchapman commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2112226185
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
Let's focus on this PR to address things as they stand today. We can always make followup improvements
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy merged PR #1625:
URL: https://github.com/apache/polaris/pull/1625
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2098370173
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
Review Comment:
This is about "Opening" a PR, no?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2103468073
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
Yep, a separate issue is a great idea. However I'm still not sure this addition to the CONTRIBUTING guide should go in if it won't be necessary after that small change.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "adnanhemani (via GitHub)" <gi...@apache.org>.
adnanhemani commented on PR #1625:
URL: https://github.com/apache/polaris/pull/1625#issuecomment-2895402281
Question here: should we be doing Squash-and-Merges when merging code in? I'm assuming that would help with some of these issues like the changelogs - but in that case, the PR title and description still needs to be set correctly by the PR author.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "RussellSpitzer (via GitHub)" <gi...@apache.org>.
RussellSpitzer commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2103194748
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
Review Comment:
I'm also not sure why we would want to require a single commit. I'd probably just drop this line and just require that folks add a meaningful summary in the PR summary.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "eric-maynard (via GitHub)" <gi...@apache.org>.
eric-maynard commented on code in PR #1625:
URL: https://github.com/apache/polaris/pull/1625#discussion_r2099793074
##########
CONTRIBUTING.md:
##########
@@ -64,32 +64,60 @@ Before starting on a large code change, please describe the concept/design of wh
The best way to provide changes is to fork Apache Polaris repository on GitHub and provide a Pull Request with your changes. To make it easy to apply your changes please use the following conventions:
-* Every Pull Request should have a matching GitHub Issue.
-* Create a branch that will house your change:
-
-```bash
-git clone https://github.com/apache/polaris
-cd polaris
-git fetch --all
-git checkout -b my-branch origin/main
-```
-
- Don't forget to periodically rebase your branch:
-
-```bash
-git pull --rebase
-git push GitHubUser my-branch --force
-```
-
- Ensure the code is properly formatted:
-
-```bash
-./gradlew format
-```
+#### Before opening a pull request
* Pull Requests should be based on the `main` branch.
+* Create a branch that will house your change:
+ ```bash
+ git clone https://github.com/apache/polaris
+ cd polaris
+ git checkout main
+ git pull
+ git checkout -b my-branch
+ ```
+* Work on the changes of your pull requests locally.
+* Ensure the code is properly formatted:
+ ```bash
+ ./gradlew format
+ ```
+* Ensure the code is passing the tests:
+ ```bash
+ ./gradlew check
+ ```
+* You may want to push your changes to your personal Polaris fork. Git will emit a URL that you can use to create the pull request. Do not create the pull request yet.
+ ```bash
+ git push --set-upstream your-github-accout
+ ```
+
+#### Opening a pull request
+
+* Before opening a pull request, squash all commits in your branch into a single commit
+* Update the subject and message of the commit to match the summary and description of the latter pull-request, GitHub will populate the PR summary and description from the "single" commit.
+* Make sure that the summary reflects the targeted area of the code base, for example `docs` or `CI`. Get inspired by [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+* The PR description should describe the background of the change and a description of the changes in way that someone who has no prior knowledge can understand the rationale of the change and the change itself.
+* If there is a matching GitHub Issue, add a separate line at the end of the commit message of the issue that the PR fixes. Do not add the issue number into the subject.
+ ```
+ Fixes #123456
+ ```
+ If the PR does not fully fix the issue, use `Related to #123456` instead of `Fixes #123456`.
+* When opening a PR consider whether the PR is "draft" or already "ready for review". "Draft" means work in progress, things will change, but comments are welcome. "Ready for review" means that the PR is requested to be merged as is (pending review feedback).
+
+#### Working on a pull request
+
+* Don't forget to periodically rebase your branch:
+ ```bash
+ git pull --rebase
+ git push your-github-accout my-branch --force
+ ```
* Test that your changes works by adapting or adding tests. Verify the build passes (see `README.md` for build instructions).
* If your Pull Request has conflicts with the `main` branch, please rebase and fix the conflicts.
+* If your PR requires more work or time or bigger changes, please put the PR to "draft" state to indicate that it is not meant to be "thoroughly" reviewed at this point.
+
+#### Merging a pull request
+
+* When a PR is about to be merged, cross-check the commit summary and message for the merged Git commit.
+* Keep in mind that the Git commit subject and message is going to be read by other people, potentially even after years. The Git commit subject and message will appear "as is" in release notes.
Review Comment:
If we can change a setting on the repo so that people writing PRs don't have to follow extra steps, let's do that
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Site/contributing: add recommendations for working with PRs [polaris]
Posted by "snazy (via GitHub)" <gi...@apache.org>.
snazy commented on PR #1625:
URL: https://github.com/apache/polaris/pull/1625#issuecomment-2896974293
> Question here: should we be doing Squash-and-Merges when merging code in? I'm assuming that would help with some of these issues like the changelogs - but in that case, the PR title and description still needs to be set correctly by the PR author.
We've decided very early on that we want to have no merge-commits.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org