-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update board policies overview page #362
Conversation
do we need the merge commit ? |
Apologies - if someone can lead me through using GitHub Desktop to avoid the merge commit, I will definitely clean up PRs in the future! Thanks all. |
AFAICT the PR is squashed when it is applied to the target repo, so why is it necessary to avoid such commits in the repo that is the source for the PR? |
@sebbASF as far as I can see in the commit history https://github.com/apache/www-site/commits/main/ We're using the Merge Commit strategy so it's not squashed. |
Surely that depends on how the PR is applied? It's normally possible to squash at time of merge. |
@sebbASF Sure. I point out that this is not the case for this repo. We can retain only the squash and commit option with .asf.yaml, or spread the knowledge among committers so that they make decisions case by case. https://github.com/apache/opendal/blob/71bddb4e3050641c2cf5897cdb7591e9787c93bb/.asf.yaml#L30-L33 |
In what way is it not the case? If there is an issue with .asf.yaml then raise a PR for it. |
In #362 we found intermediate merge commit can cause the commit history hard to read. Thus, I propose to leave only the "Squash and merge" button to make it clear that we always squash the whole PR into one commit on merging.
This removes the draft marker and cleans up pointers to any well-recognized MUST links, which include some sort of board or specific policy-setting officer policy on them, versus some SHALL/MAY links which are best practices or similar.