| Age | Commit message (Collapse) | Author |
|---|
|
While the trailing brackets [] are markdown compatible they break the links with the contributor-site link generator when the content is ingested.
|
|
This updates the release notes guide to meet style guidelines, as well
as including additional advice on release notes from community
feedback.
|
|
|
|
|
|
|
|
|
|
This adds a dedicated section about the review of release notes.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
|
|
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
|
|
|
|
|
|
Signed-off-by: Jorge O. Castro <jorgec@vmware.com>
|
|
Cherry picks are now mostly handled primarily through automation,
including their release note block. In some cases that release
note automation may fail (multiple candidate release notes from
which to pick) and human intervention is required, but this amounts
to just adding the otherwise normal `release-note` block in the
pull request description.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
|
|
/devel/sig-release - URLs updated
|
|
|
|
|
|
Minor cleanup in pull-requests.md
|
|
If a contributor reads the pull request template upon creating a PR then
they will get hints, but ahead of a PR there has not been sufficient
documentation of when release notes are required for a change, how a
contributor should indicate that a change needs notes, or what the note
text should be. To help address this, this commit adds a first set of
release notes documentation for reference by the contributor guide.
|
