Functional ownership of project templates, forking and mirroring functionality
The functionality of project templates (and forking) is based on project import/export which is a feature built and owned by groupimport and integrate
Historically groupimport and integrate has been the owner of project templates until groupsource code became the DRI for it.
There's been a fair amount of issues where issues related to project templates have been worked on by the two teams:
- Import/Export - Protected Branch: Settings not ... (#387014 - closed)
- Custom group-level project templates do not imp... (#11775 - closed)
- Custom group-level project templates do not imp... (#390743 - closed)
- Some settings are not carried over when creatin... (#369946)
- Cannot fork into a group where a user has Devel... (#413440 - closed)
- Gitlab Import/Export & Custom Templating misses... (#430195)
Recently, groupimport and integrate was asked to work on some of those issues because of the feature's dependencies on import functionality the even though groupsource code being the DRI for the category.
From the Product perspective, splitting the import and templates (and forking) sounds like a good solution. It would allow:
- To have a clear ownership of the issues related to templates and forking
- To avoid cases when we make change to importer code and unwillingly affect templates, forking and mirroring functionality as well.
Forward thinking: As groupimport and integrate plans to eventually deprecate import/export functionality in favour of migrating by direct transfer - would groupsource code take over the importer code then?
There are a couple of things that I'd like to discuss openly in this issue:
- Are there particular topics related to project templates that rely on the Import code or is it the entire feature?
- Does it make sense to separate import code from template functionality?
- If so, what is required to get rid of the dependency on import code?
- What are the tradeoffs?
- What's the estimated effort?
- ...