thank you very much to pick up this task (and the other text related ones). For the future please try to write more useful commit messages. It is especially important to reference the addressed issues to allow better traceability to find out why code changes have been introduced by future readers.
This repository has been setup to link to bugs.cacert.org. You can reference issues in the bug tracker like this: #1526
Hi @bmc,
thank you very much to pick up this task (and the other text related ones). For the future please try to write more useful commit messages. It is especially important to reference the addressed issues to allow better traceability to find out why code changes have been introduced by future readers.
This repository has been setup to link to bugs.cacert.org. You can reference issues in the bug tracker like this: #1526
Please read [How to Write a Git Commit Message](https://cbea.ms/git-commit/) for a general introduction to good commit messages and [the Gitea documentation](https://docs.gitea.com/usage/automatically-linked-references) for specifics on referencing bugs.
Kind regards
Jan
We should decide on the canonical location (I suggest 2.) and get rid of the other ones. We could have a release branch in 2. and add this as a submodule in 3. to avoid duplication.
Changes to the policy would then be pull requests in 2. and would be released by merges into the release branch.
Best regards
Jan
We have multiple locations for policy documents now:
1. http://svn.cacert.org/CAcert/Policies/ (the original policy section of the old Subversion repository)
2. https://code.cacert.org/cacert/cacert-policies (the repository that was migrated from the Subversion variant where @alkas started work on drafting the new CPS)
3. the copies in this repository (https://code.cacert.org/cacert/cacert-webdb/src/branch/main/www/policy)
We should decide on the canonical location (I suggest 2.) and get rid of the other ones. We could have a release branch in 2. and add this as a submodule in 3. to avoid duplication.
Changes to the policy would then be pull requests in 2. and would be released by merges into the release branch.
Best regards
Jan
I also agree that it's better to write commit messages in clear text (reason why and what is changed), and then perhaps also refer to the underlying reason for the change.
I also agree that it's better to write commit messages in clear text (reason *why* and *what* is changed), and then perhaps *also* refer to the underlying reason for the change.
I also understand and agree with your comment about my commit messages, Jan. I generally do not write a lot there since I try to refer to the underlying ticket, but will try to improve in the future.
I agree with the choice of #2.
I also understand and agree with your comment about my commit messages, Jan. I generally do not write a lot there since I try to refer to the underlying ticket, but will try to improve in the future.
content approved, the PR should be made against the files in https://code.cacert.org/cacert/cacert-policies too. See the discussion in https://code.cacert.org/cacert/cacert-webdb/pulls/23#issuecomment-342 for reasoning.
Corrected text.
Hi @bmc,
thank you very much to pick up this task (and the other text related ones). For the future please try to write more useful commit messages. It is especially important to reference the addressed issues to allow better traceability to find out why code changes have been introduced by future readers.
This repository has been setup to link to bugs.cacert.org. You can reference issues in the bug tracker like this: #1526
Please read How to Write a Git Commit Message for a general introduction to good commit messages and the Gitea documentation for specifics on referencing bugs.
Kind regards
Jan
We have multiple locations for policy documents now:
We should decide on the canonical location (I suggest 2.) and get rid of the other ones. We could have a release branch in 2. and add this as a submodule in 3. to avoid duplication.
Changes to the policy would then be pull requests in 2. and would be released by merges into the release branch.
Best regards
Jan
I agree that #2 is the best place for the document repo.
I also agree that it's better to write commit messages in clear text (reason why and what is changed), and then perhaps also refer to the underlying reason for the change.
I agree with the choice of #2.
I also understand and agree with your comment about my commit messages, Jan. I generally do not write a lot there since I try to refer to the underlying ticket, but will try to improve in the future.
content approved, the PR should be made against the files in https://code.cacert.org/cacert/cacert-policies too. See the discussion in #23 for reasoning.
I have created a PR for the changes to the documents in the Policy repository.
Reviewers