[policies] Add policy for TencentOS

[ZoeDong]

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname [email protected]?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3417
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[TurboTurtle]

I'm going to raise the same concerns I have raised previously about the recent trend of adding policy support for RHEL clones and then nothing else being done with them, and the distro in question seemingly going silent not too long after.

[arif-ali]

I'm going to raise the same concerns I have raised previously about the recent trend of adding policy support for RHEL clones and then nothing else being done with them, and the distro in question seemingly going silent not too long after.

Ah, yes, we discussed on IRC on this too; most of the policies are extending RedHatPolicy other then ubuntu, suse and debian. and they have limited input other than branding, like you suggested in the above comment.

Does that mean, we want to de-brand, and get rid of some of the policies?

[TurboTurtle]

Does that mean, we want to de-brand, and get rid of some of the policies?

Not so much that, but moreso that I think we should be a bit more particular about what policies get added - what's already in the tree is already there however.

So, for instance if a new distro wants to add an sos policy and has a new/different package manager (or combination of package managers) then that makes sense to me. Or if there's a new distro with professional support offerings. Or one that is trying to carve out a name in the OSS community. Or a distro needs specific changes to collections for certain plugins (i.e. a new tagging class is needed). Etc, etc..

What I don't want to encourage though is collecting a bunch of policies that are all clones of $some_other_distro and the only the difference is the branding and the website printed in our disclaimer. Especially if the plugins have no difference between these distros (e.g. no need for different tagging classes), or if we'll never see any further contributions to upstream from them because there's only a single entity using such an in-house distribution.

[ZoeDong]

My original intention is to provide basic distro information when using sos. We will consider providing more support. Before that, I will close this PR. Thanks for your reply.