release-notes.d: initial directory for release note yaml snippets

[zonggen]

This directory stores the Fedora CoreOS release note yaml snippets which will be picked up by fedora-coreos-releng-automation/coreos-release-note-generator [1] script to produce the final release-notes.yaml for a release.

Release notes will be organized according to the origin of the change, i.e. the project name. Otherwise miscellaneous changes will be stored under miscellaneous. Therefore, the schema of each yaml snippet is designed as follows:

# Each yaml file consists of a list of dictionaries which looks like this
- component (required): [Custom Project Name] | miscellaneous
  subject (required): xxx
  body (optional): xxxxx

[1] https://github.com/coreos/fedora-coreos-releng-automation

Related: coreos/fedora-coreos-tracker#194
Signed-off-by: Allen Bai abai@redhat.com

[zonggen]

Updated with a component field instead of enforcing naming convention. Currently thought on component is to support four types of components: [Custom Project Name] | general | bugfix | security.

[dustymabe]

Updated with a component field instead of enforcing naming convention. Currently thought on component is to support four types of components: [Custom Project Name] | general | bugfix | security.

I think there might be too much collision there. For example, what if I have a significant bugfix in Ignition? I think we have two options here:

1. add a type: field with options like enhancement | bugfix | security.
2. just ignore type: for now and add it later

For component: maybe the word miscellaneous would be better than general. So our options would be component_name | miscellaneous.

[zonggen]

Updated the component to allow either [Project Name] or miscellaneous.

[dustymabe]

LGTM - nice work @zonggen

[dustymabe]

Maybe let's squash the two commits into one?

[zonggen]

@dustymabe I formatted the doc a little bit and added an example for the intermediate release-notes.yaml file that consists a next-release field (https://github.com/coreos/fedora-coreos-config/pull/550/files#diff-501cdb98b3adaa694d31c5775aa02a46R14-R29), could you take another look?

[dustymabe]

Can we rename README to README.md so GitHub will format the file?

[zonggen]

Simplified README.md and squashed commits.

[dustymabe]

LGTM - I think we'll need to also do this for next-devel?

[dustymabe]

Will having the example.yaml file make things harder in the implementation? Were you planning to just ignore that file in the code? I like having it there so people can copy and paste, but want to make sure we account for it.

[zonggen]

Were you planning to just ignore that file in the code?

@dustymabe Yes, I was writing the releng code such that:

• empty files are ignored
• note item with empty component / subject is ignored (since they are required fields)
• empty body is removed to clean up the final release note

[zonggen]

Will open another PR to next-devel, thanks for the reminder!

EDIT: Opened #570