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-communitheme as the new based repo (but renamed), so that we keep bug reports and PR, and move gnome-shell-communitheme bugs to that one.
- PR: there is no way to move PRs between repositories though. As on that plan, we keep
gtk-communitheme PRs, we only need to clean up gnome-shell-communitheme PRs 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).
Thoughts?
6 Likes
Thoughts?
I think you sorted it out already 
I totally agree on keeping gtk-communitheme as main and only repo (renamed):
- people often open bugs on the wrong repo, since they don’t know the difference between them
- gtk-communitheme is the most active and the one with the longest history. I think there won’t be any problem in re-proposing PRs from gnome-shell-communitheme, it would be a good time to re-analyze them as well, since some are old.
There’s also the flatpak repo. I don’t know how we would want to work with that. It’s basically just one line to change every time we update stable release, so my intention was to automate this step as well.
3 Likes
Sounds like a good (and needed) idea.
As Carlo said, the shell PRs are really easy to save. We need the agreement from @godlyranchdressing or at least @c-lobrano to close one or two PRs since they are very old (I can push those changes, if wanted, in later PRs).
There is also the PR (which is actually more an issue ) about the user and panel icons in GDM at first login (not the lockscreen):
https://github.com/ubuntu/gnome-shell-communitheme/pull/56
And there is the decision about app grid or ubuntu logo which you wanted to make after your return from that gnome conference 
My idea would be: create issues about unsolved problems rather than PRs on the gtk-repo and delete super old PRs.
5 Likes
I think before we do this merge, I just diffed again the repo and I think it would be nice to do some cleanups, I’m unsure anyone has time to do it, but I list what I noticed here, just in case someone wants to volunteer
- There are a lot of .old files, shouldn’t those be removed? VCS is used to go back in time
- I found some commented paragraphs css code. I think those should be removed.
Making sense? Any other cleanup I’ve missed listing?
1 Like
Edit:
the checkboxes are in the gtk repo. I can remove those.
The comment code is in gtk files or shell files?
Nice! Please yeah, it’s time for cleanup
I only checked the gtk repository, but I guess the shell ones would need a rereview as well.
Also, I think we should add comments on section to tell “this section is for…”, that will help, and we may be able to upstream some of the changes later to Adwaita (the GNOME team is opened to it, but we need to document first).
1 Like
That could mean they like our theme and want to make it adwaita-blue ? ;O
The best would be if @c-lobrano does the gtk comments and I do the shell comments (or Aaron).
But I’ll start with removing the old assets.
2 Likes
Do you think upstream will accept also separating content in dedicate files? Like headerbar.scss, button.scss
This would help a lot when looking for fixes or content to change
1 Like
If we are clear in our experience and why/what we should have some separation, I’m sure upstream will listen to it and that’s a good thing to ask for (maybe for incoming GTK4).
1 Like
Ok, let’s doing it step by step, comments first
1 Like
And here we go! Please test the snap produced by https://github.com/ubuntu/gtk-communitheme/pull/628. I plan to merge it tomorrow morning. I have tested the snap itself and didn’t notice any regression.
As told on the PR description:
This is the merge of all communitheme related repositories and moved into subdirectory.
In addition, it fixes some issues in the build system (duplicated icons, wrongly assigned names) and ensure that we can change via a single “project_name” the whole directories and theme outputs.
A single source package is available creating the different binary packages (renamed as well).
The CI system is kept as well, and reshaped building the gtk-common-themes snap.
For backward compatibility, symlinks and other renaming are done in the snap itself, which will still keep the name “communitheme”.
This will make the incoming rename easy! Once merge, I’ll temporarily rename the repository as simply “communitheme” until we reveal the definitive new name. As said, I’ve used the opportunity to do some cleanups, but some more followup cleaning is possible.
For instance:
- I moved the session for people contributing upstream. It’s now “Communitheme (for devs or testers)”. However, this session isn’t shipped in any debian package (as it will soon be the ubuntu session, and the snap has its dedicated session)
- I think all AUTHORS (so, all of you + regular external contributors) deserves to be in a
AUTHORS file, anyone want to file up the initial list? (I removed the CREDITS from sound repo so that we only use one file)
- The issue template is now the one from Suru, any volunteer to add specific instructions for communitheme?
- For keeping things consistent and short, I removed some explanations when merging the various README and I think they should be merged into the wiki (same, asking for volunteers/victims ;))
We're clipping out things like 'button-pressed' and 'service-logout', and working towards shorter and less intrusive, more refined audio set.
The system notifications are played on a wooden percussion instrument to give the theme an african feeling. To make the theme feel light and responsive, the sounds are very short and there's no reverb or delay added.
The desktop-login sound is based on [Jouni Helminen's awesome work for Ubuntu Touch](https://youtu.be/XnyopqW3Af8?t=2m48s).```
Of course, any other cleanup or changes to README.md or CONTRIBUTING are welcome! Note that I didn't touch the Suru icon theme README and LICENSE so that it's easier to continue merging from upstream repo.
- For people testing the theme building the upstream repository, we now generate the .desktop and schema overrides file when installing. A new session should be available after reboot. I have adapated the instructions for that. I haven’t tested on a clean machine than one, so if you notice any regression, do not hesitate to yell!
- There is no more -session package as this will be the ubuntu-session package providing that in Cosmic under the regular “Ubuntu” session once we switch.
Does it look good? Any takers for those cleanups?
1 Like
done, everything is fine 
I can draft the AUTHORS and the issue template (hopefully) late today
2 Likes
Is the e-mail mandatory in an AUTHORS file? I could find only a few of them
Aaron Papin <godlyranchdressing@gmail.com>,
CraigD,
Carlo Lobrano <c.lobrano@gmail.com>,
Didier Roche <didrocks@ubuntu.com>,
Frederik Feichtmeier,
Mads Rosendahl,
Merlijn Sebrechts <merlijn.sebrechts@gmail.com>,
NusiNusi,
Paz-it,
Stefan Eduard Krenn,
jaggers,
mivoligo,
nana-4,
taciturasa
vinceliuce <vinceliuice@hotmail.com>,
ya-d,
yazub,
EDIT:
- opened a PR with the above AUTHORS file, with steps to complete
-
@didrocks I can’t see the
settings tab in gtk-communitheme project (for the issue template), while I can see it on my repositories. There’s some kind of permission to be enabled?
And this is done! Now everything is merged into a single repo, which I just renamed to https://github.com/ubuntu/communitheme! Update your remotes (even if github does the redirection for you).
I plan to delete the other repositories soon to avoid any mistake, anyone opposing to it?
Note that when we merge the Suru repo, we need to git mv any new icons in the icons/ subdirectory.
Thanks for doing this! Email aren’t mandatory, it’s more a FYI thing. (Note: you can find them in git messages for people who committed).
On your second question, only admins have access to the settings, as there is some permission and third party credentials in it, this is why those settings aren’t accessible.
2 Likes
of course