Mock core configs - README.md with maintainers and issue trackers

[FrostyX]

See also #1171

We have a lot of chroots, so it is not uncommon, that some of them break from time to time. Most of the reports that I've got were about Fedora ELN but there were others as well. People usually report them as a Copr issue, so I need to point them here (and make sure the maintainer knows) or point them to the distribution issue tracker, which I don't remember from the top of my head.

Hopefully, this will improve the situation.
What do you think?

[FrostyX]

The table is missing some chroots, I can add them if needed. Also, I mainly used the original contributors of the configs as maintainers. We should probably tag them here and ask if they are okay with that.

[xsuchy]

I would prefer this data in configs itself and generate the table from the configs... but this is definitely improvement. So +1

[praiskup]

Awesome, thank you for the PR!

The table is missing some chroots

I think it is fair to state that we maintain CentOS & RHEL chroots, wdyt? ~~ Simply add a link to our tracker.~~ Edit: No, the table contains distribution tracker links; so perhaps we should add there links for opening a bug or a support ticket?

[praiskup]

I think it is worth underlining when users should contact 1) us to fix the config or 2) the distro tracker because the distribution is broken (I'd put Distribution issues header for the colum with links). I.e. clearly tell them that for configuration bugs they should open an issue against us, or even better, send a patch.

[FrostyX]

I think it is fair to state that we maintain CentOS & RHEL chroots, wdyt?

Sure

I think it is worth underlining when users should contact 1) us to fix the config or 2) the distro tracker because the distribution is broken (I'd put Distribution issues header for the colum with links)

I tried to explain that in the text above the table. Should I re-word or highlight some of its parts?

[praiskup]

I tried to explain that in the text above the table. Should I re-word or
highlight some of its parts?

I think the wording is nice. Just that the table gets all the reader's
attention; I'd change the table header, something like s/Issue
Tracker/Distribution or repository issues/. Or anything you like.

[praiskup]

What if we created a proper user documentation page, e.g. referenced directly on homepage? We could keep README.md as you propose, but just link the new docs?

[FrostyX]

I added the missing CentOS and RHEL chroots and tried to improve the config issue vs distro issue readability.

What if we created a proper user documentation page, e.g. referenced directly on homepage? We could keep README.md as you propose, but just link the new docs?

I don't have any preference. We can either reference this README from the documentation or we can move the page to the documentation and have only a README with the link to the documentation. It's up to you. I think this would be a good place where to mention it https://rpm-software-management.github.io/mock/#chroot-config-files

[praiskup]

I added the missing CentOS and RHEL chroots and tried to improve the config
issue vs distro issue readability.

Nice, I really like it now! Thank you.

I don't have any preference. We can either reference this README from the
documentation or we can move the page to the documentation and have only a
README with the link to the documentation. It's up to you. I think this would
be a good place where to mention it
https://rpm-software-management.github.io/mock/#chroot-config-files

I'd probably prefer a separate documentation page, referenced both by the
README file and the place you mention (index.md is quite long now to add
the table directly there).

The benefit is that we could "quickly" update the documentation page when needed.
The README.md is distributed with release tarballs/RPMs and old
RPMs would be prone to have outdated info..

Of course, we can merge as-is, and I can do this change later if you prefer.