PR progress checklist (to be filled in by reviewers)
[x] Changes to documentation are appropriate (or tick if not required)
[x] Changes to tests are appropriate (or tick if not required)
[ ] Reviews completed
What type of PR is this?
Primary type
[ ] [build] Changes related to the build system
[ ] [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
[ ] [ci] Changes to the continuous integration configuration
[x] [feat] A new feature
[ ] [fix] A bug fix
[ ] [perf] A code change that improves performance
[ ] [refactor] A code change that neither fixes a bug nor adds a feature
[ ] [revert] A change used to revert a previous commit
[ ] [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
Secondary type
[x] [docs] Documentation changes
[ ] [test] Adding missing or correcting existing tests
Does this PR introduce a BREAKING CHANGE?
No - whilst the default behavior technically changes, practically the default behavior before this change would print an error message, hence nobody could have been using it so far.
Related issues and/or pull requests
Describe the changes you're proposing
On distributions without separate available/enabled directories it feels unnecessary having to declared enabled: true in every configuration block. I propose "enabling" configurations by default unless specified otherwise, instead of printing an error about enabled missing from the dict.
Pillar / config required to test the proposed changes
PR progress checklist (to be filled in by reviewers)
What type of PR is this?
Primary type
[build]
Changes related to the build system[chore]
Changes to the build process or auxiliary tools and libraries such as documentation generation[ci]
Changes to the continuous integration configuration[feat]
A new feature[fix]
A bug fix[perf]
A code change that improves performance[refactor]
A code change that neither fixes a bug nor adds a feature[revert]
A change used to revert a previous commit[style]
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)Secondary type
[docs]
Documentation changes[test]
Adding missing or correcting existing testsDoes this PR introduce a
BREAKING CHANGE
?No - whilst the default behavior technically changes, practically the default behavior before this change would print an error message, hence nobody could have been using it so far.
Related issues and/or pull requests
Describe the changes you're proposing
On distributions without separate available/enabled directories it feels unnecessary having to declared
enabled: true
in every configuration block. I propose "enabling" configurations by default unless specified otherwise, instead of printing an error aboutenabled
missing from the dict.Pillar / config required to test the proposed changes
Debug log showing how the proposed changes work
Documentation checklist
README
(e.g.Available states
).pillar.example
.Testing checklist
state_top
).Additional context
n/a