Hey Communitheme team!
Once we elect the new name for the theme, which will thus transition the current repositories to new ones, I think we can make easier for contributors and ourselves as well by revisit our project structure.
Right now, we have 6 repos (GTK2/3, GNOME Shell, suru fork, sound, cursor - which is going to be removed and replaced by suru fork icon set slightly modifier, snap and build system helpers). There is as well
communitheme-set-default by the snap is blocked on snapd implementation, let’s discare it for now.
To consolidate this, we can create a single repo containing GTK2/3, GNOME Shell, suru fork and the cursor themes +, build system (snaps and debs). This way, contributing to the “ubuntu default theme” will only be contributing to this repository. Also, we can tag one release and produce automatically a source tarball for others to pick it up.
To ease and speedup cosmic integration, we also may use a debian package for it (there are quite some work to be done on snapd side to get the same level of integration than a debian package for a theme) and still ship the “communitheme” snap for bionic.
Now, on the migration itself:
- it’s possible to merge in a single git repository the history of all git repository, so don’t be afraid by this. We can continue as well merging suru to this new repository at a regular bases. Basically, we don’t loose our history, so good!
- bugs: we can migrate bugs via scripts (it will be reattributed under the migration owner, but quoting who reported it and a comment is written on the previous bug location. The 2 projects having non closed bug filed against them are: gtk-communitheme and gnome-shell-communitheme. I suggest we use
gtk-communithemeas the new based repo (but renamed), so that we keep bug reports and PR, and move
gnome-shell-communithemebugs to that one.
- PR: there is no way to move PRs between repositories though. As on that plan, we keep
gtk-communithemePRs, we only need to clean up
gnome-shell-communithemePRs or repropose them manually under the new repo.
This would require some work to merge the git repo, move bugs, retitle a repo, deprecate the other ones, and changing the build sytem, snap implementation and debian package. However, I feel that when we move to our definitive name is a good time for that, it will ease contribution, ensure bugs are reported in a single (correct) place and ease the currently (working) build system, but using a more official build.snapcraft.io (each commit can thus release in edge).