| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GitHub guide on contributing file says: "Decide whether to store your
contributing guidelines in your repository's root, docs, or .github directory."
https://help.github.com/articles/setting-guidelines-for-repository-contributors/#adding-a-contributing-file
But there's really no advantage to keeping it in the hidden .github/, since
these are public and really belong together with the other documentation.
We can still keep the issue templates under .github/, since they are not really
documentation on their own.
Updated the links pointing to CONTRIBUTING.md to refer to the one in docs/.
|
|
|
|
|
|
|
|
|
| |
The docs/ directory is special in GitHub, since it can be used to serve GitHub
Pages from, so there's a benefit to switching to it in order to expose it
directly as a website.
Updated references to it from the documentations themselves, from the
CONTRIBUTING.md file and from Meson build files.
|
|
|
|
|
|
| |
Github now has issue templates in the web interface, and allows
more than one to be specified. Let's split our single template
in two: bug report and RFE.
|
|
|
|
|
|
|
|
|
| |
I figure sooneror later we'll have more of these docs, hence let's give
them a clean place to be.
This leaves NEWS and README/README.md as well as the LICENSE texts in
the root directory of the project since that appears to be customary for
Free Software projects.
|
| |
|
|
|
|
|
| |
Since the switch to meson this information is no longer valid. HACKING already documents how to run the test suite.
See #6642
|
| |
|
| |
|
| |
|
|
|
|
| |
It's for the person filling in the form, not for people reading it later.
|
|
|
|
| |
The issue list page thinks those are in fact todo items.
|
| |
|
|
|
|
|
|
|
|
| |
We *do* have the occasional security issue, where it would be nice to have
non-public disclosure and time to fix the issue before it's fully public. Our
github infrastracture does not make it easy to report vulnerabilities in
confidential manner, so let's leverage the distro mechanisms for that. I
think we're better off with this solution than leaving it up to individual
reporters to discover some mechanism on their own.
|
|
|
| |
Only project members can do it.
|
|
|
|
| |
build tree (#3763)
|
|
|
|
|
| |
I put it in .github, so it doesn't stand out too much; after all
it's not interesting to most people.
|
| |
|
|
|
|
|
| |
GitHub displays this file poorly, because it preserves the newlines.
Let's try how things look without any wrapping.
|
| |
|
|
|
|
| |
a checkbox
|
|
|
|
|
|
| |
As documented here:
https://help.github.com/articles/creating-an-issue-template-for-your-repository/
|
|
As suggested by:
https://github.com/blog/2111-issue-and-pull-request-templates
|