update depricated 303 rule, add name[missing] rule

[AliMehraji]

Changes:

• Update deprecated 303 rule in molecule/default/converge.yml
• Also add # noqa: name[missing] to prevent redundancy tasks name.
• add spaces around ansible_distribution and ansible_os_family in tasks/main.yml for Load OS-specific vars

ansible-lint Errors and Warnings:

warning[outdated-tag]: Replaced outdated tag '303' with 'command-instead-of-module', replace it to avoid future errors

name[missing]: All tasks should be named.

[cschindlbeck]

I think it is not very elegant to introduce additional vars in main like docker_obsolete_packages_redhat, see alternative here #489

[AliMehraji]

I think it is not very elegant to introduce additional vars in main like docker_obsolete_packages_redhat, see alternative here #489

yes, you're right the docker_obsolete_packages could be in RedHat.yml and Debian.yml in vars

[AliMehraji]

Hi @geerlingguy,

I noticed that other PRs have been reviewed and merged, but mine hasn’t even been acknowledged. I just want to understand if there’s a specific reason for this—whether it's an issue with the changes, or something else. If this PR isn't a good fit, I’d appreciate clarity on why so I can either make the necessary adjustments or close it.

I’d really appreciate a response. Looking forward to hearing your thoughts.

Thanks.

[geerlingguy]

Hi! I maintain a couple hundred projects, so typically if a PR is over 5-10 lines long and isn't fixing an egregious/obvious bug, it's much lower priority for me to review.

I typically like to merge PRs that either fix an obvious bug (e.g. CI failing, or install failing, something broken for everyone), or are focused on one tiny aspect (like tweaking one or two small parameters).

When I see 8 files and 63 lines changed, I know that means at least 30 min to an hour for a PR review, and to protect my time with family, work, and very limited time to review OSS project contributions that don't directly impact my own use of the role, unfortunately most of the time that results in ignoring the work.

It's part of my framework for preventing burnout and closing all contributions to my roles—it is not fun, necessarily, for contributors, but it is the only way I've been able to keep 200+ projects running on GitHub without burning myself out and killing them all off: https://www.jeffgeerling.com/blog/2022/just-say-no

If you don't agree with my development philosophy, that is fine too, we are all entitled to our opinions!

In terms of getting changes merged, it would help if they were split into smaller PRs with very clear and obvious benefits to the role's ongoing maintenance or preventing future problems.

[AliMehraji]

Hi! I maintain a couple hundred projects, so typically if a PR is over 5-10 lines long and isn't fixing an egregious/obvious bug, it's much lower priority for me to review.

I typically like to merge PRs that either fix an obvious bug (e.g. CI failing, or install failing, something broken for everyone), or are focused on one tiny aspect (like tweaking one or two small parameters).

When I see 8 files and 63 lines changed, I know that means at least 30 min to an hour for a PR review, and to protect my time with family, work, and very limited time to review OSS project contributions that don't directly impact my own use of the role, unfortunately most of the time that results in ignoring the work.

It's part of my framework for preventing burnout and closing all contributions to my roles—it is not fun, necessarily, for contributors, but it is the only way I've been able to keep 200+ projects running on GitHub without burning myself out and killing them all off: https://www.jeffgeerling.com/blog/2022/just-say-no

If you don't agree with my development philosophy, that is fine too, we are all entitled to our opinions!

In terms of getting changes merged, it would help if they were split into smaller PRs with very clear and obvious benefits to the role's ongoing maintenance or preventing future problems.

Thank you for your response—I really appreciate the insight into your process and development philosophy. I completely understand the need to manage time effectively while maintaining so many projects.

That said, I’d love to find a way to align my contributions with your workflow. Some changes, while appearing large in terms of the number of files, are mainly about keeping dependencies or configurations up to date.

For example, the docker_obsolete_packages change affects multiple files (add two new files: vars/Debian.yml, vars/RedHat.yml, update: tasks/setup-RedHat.yml, defaults/main.yml, and the README). While it touches five files, it's fundamentally a small, necessary update. Given this, how would you recommend structuring such changes to fit within your preferred review scope?

To make things easier, I’ll close this PR and open a new one focused solely on the docker_obsolete_packages variable. It will still touch five files, but I hope the context makes it clear that the change is straightforward.

Thanks again.

[geerlingguy]

@AliMehraji - Indeed, if you can break out the changes into individual PRs, that will let me get to reviewing them more quickly and independently :)

If it's the same change across three files, that's a lot quicker to review than that plus a few other small changes in one PR.