The PR https://github.com/ComplianceAsCode/content/pull/5606 introduced
a large number of changes that may break patches, but those changes were
much needed in the project. So I think that we should use this
opportunity to introduce more changes, so we introduce only one pair of
versions between which things could break, as opposed to breaking many
times in a row in the future.
So what I think we could consider?
- Rename description, rationale to html_description, html_rationale.
Reason: We could start to introduce Markdown input, and doing it this
way would allow us to do it gradually. We probably want to have html as
a canonical form, but we could offer more possibilities for content authors.
- Restructure project's folder structure - right now, the list of
products is really long, which makes the project page too long. Having
products in a separate directory would also allow us to get a list of
supported products programmatically from the filesystem.
- Put macros where they belong. We have plenty of boilerplate in the
project, and macros can keep the code readable and free of duplicates.
Moreover, if people use a macro to e.g. instantiate an XCCDF variable,
we can change the underlying implementation without breaking the public API.
Most of these changes is just about crafting and running a sed command,
plus comparing the result before and after - I have in mind large-scale
changes that don't require a large amount of time to perform.
What do you think? Do you have other suggestions you would add to the list?
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
