Hi Matěj, Thank you very much for opening this topic.
Please find responses inline. On Wed, Jul 29, 2020 at 5:59 PM Matej Tyc <[email protected]> wrote: > > 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. In general I would like to reduce breaking changes to minimum. > > 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. I like the idea of using Markdown instead of HTML. However, I think that renaming the keys will make the rule.yml format less understandable. I think everyone understands `description` and `rationale` intuitively. But having `html_description` and `description` at the same time will confuse people. We should keep only `description` and `rationale`. I think it's possible to support HTML and Markdown at the same time and the build system could detect the format automatically. > > - 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. Do I understand it well that the concern is that the product directories are all located in the project's root directory? I don't think this is a problem. I admit that 67 items in the root directory can't be skimmed in a second, but it doesn't cause any big trouble. People usually know which product they want to work with and they do `cd product_name` right away. I'm against this change. The community members have their patches that will all break because all the paths will change. The fact that the project page looks long doesn't justify such a big change. And you can get the list of products programmatically even in the current layout by searching for all directories containing product.yml. > > - 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. I like this proposal. > > 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. You have proposed putting macros where they belong which will involve manual work. > > What do you think? Do you have other suggestions you would add to the list? I have some ideas, but most of them require a larger amount of time to perform. - Continue with decommissioning Bash remediation functions in favor of Jinja macros, because the mechanism of including the shared Bash functions is troublesome. - Decouple content from the build system. - Speed up the build. - Unify platform assignment. This is now solved by a combination of prodtype, platform and file name. I find this complex. Regards > _______________________________________________ > scap-security-guide mailing list -- [email protected] > To unsubscribe send an email to > [email protected] > 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/[email protected] -- Jan Černý Security Technologies | Red Hat, Inc. _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
