TBH I still think we should just merge all the community templates into core.
We have a way already of defining which plugins are required for templates to work and we don’t show templates that have unmet requirements. Alternatively, we can move plugin-specific templates to the actual plugin that uses them, like we currently sync job templates to rex instead of to core.
it’s confusing to users when they are sent to a different repo for contributing to a template, and to a contributor who is properly directed it doesn’t matter if the repo includes only the templates or a whole bunch of other code. on the contrary, if the contribution is done in core it also gets tested right there in the PR and we can tell right away if a snapshot needs updating. PRs in community templates also have a much slower response rate since less people are going over them.
As the one doing the release work for the past year and half, it’s a pain every release to sync them, make sure they work and track which fix landed in what release (and what needs to be backported to fix bugs). There is a good reason we use redmine for tracking issues.
There has been talk for years now on how we can keep community templates and better sync them to core and test them but no one has actually implemented anything other than suggesting that we can improve.
Lets move them to core and get this over with.
I just think it’s too much burden for users. For example from now on, a redmine ticket will be required for small one liners. Previously, templates did not have even RM project. Looking in the git history, we do get quite many contributions from our users. Maybe we can find easier workflow for these small fixes.
However, I do not insist on this. If you think syncing is the problem, then let’s do it
- would it be possible to use a git submodule? does this make sense?
- would it be possible to change the rule that a redmine ticket is necessary for certain directories within core?
for me, it would also be OK to move the templates OUT of foreman and package them in a separate RPM. Opinions?
I suggest to stay away from gitmodules at all costs. Let’s simply merge it into core then.
Not against, however not a goal I think.
With the 2.1 cycle under way, this came up as a pain point again in a few cases:
- Some templates were renamed, causing 2.1.0-RC1 to actually ship with duplicate templates.
- A fix that was merged into community templates had a bug that was only caught when syncing the template (due to snapshot tests). As a result several commits had to be cherry-picked post branching in both repos and required an extra cycle of template syncing (https://github.com/theforeman/foreman/pull/7644#issuecomment-628010147)
- missing mapping of commits in community templates to redmine made it difficult to tell which changes were needed to be pulled into the 2.1-stable branch for the next RCs. Each change to the community templates at this stage requires extra work to get into the 2.1 branch of core instead of only cherry-picking a single commit, and brings risk of snapshot or other template testing breaking after syncing.
My proposal to move forward (which also addresses some of the previously discussed concern):
- provisioning, partition and report templates will be synced and live in core. Metadata can be used to make sure templates are only seeded if a dependent plugin is installed.
- job templates will live either in the REX repo (for the ssh templates) or the respective plugin adding a REX provider (e.g. ansible/salt). We might want to look into template metadata as well in only seeding templates matching installed plugins.
- The community templates repo will be archived and users will be asked to submit PRs to either Core or REX/providers.
- Core maintainers will assist any community contributor in creating a redmine issue for pull requests or with fixing tests/snapshots if needed.
Onboard! I’ve wanted this simplification for a while with respect to cherry picking and releases.
Two ideas to help with this:
- Add a new label to specifically call out template PRs on the repository for easy filtering and review
- Have our prprocessor provide a link to issue creation URL (e.g. https://projects.theforeman.org/projects/foreman/issues/new for Foreman) if a ‘Fixes/Refs’ is not detected in a comment on the PR
One more thing is how to handle open PRs, this will be quite disturbing change we should think it thorugh.
There are just 20 open PRs right now, many of them inactive for a long time. Lets see what can be merged and merge them before the last sync, and ask the remaining contributors to reopen the PRs against the relevant repo or help them to do so if needed.
We discussed this at a meeting of core maintainers last week, and came to agreement that we will be doing the final sync and archiving the repo right after 2.1 GA - which is currently planned for June 16th. In the meantime we will try to get as many PRS as possible merged into the community-templates repo to reduce the effort of having to reopen them against core or plugin repos. Expect the repo to be officially retired by June 21st.
If you have any open PRs that you don’t expect will be merged by then, feel free to close them and open against the new home of the template, but if you do so before the final sync make sure to mark your PR as draft for now so it isn’t lost by mistake when syncing.