I am sorry for perhaps causing any confusion or misunderstandings :(. I suck at conveying information. Let me try a slightly different approach that coincides with my thought process... We are really approaching two things that are related in this discussion. 1. Registry Replacement 2. GIMP Asset Installer Registry Replacement ================ My initial thoughts were to build out a replacement for the functionality that was available in regsitry.gimp.org (rgo). I listed in my initial email what I thought was the essential functionality: 1. Host assets for GIMP. 2. Asset description page to inform users what it is, etc. 3. Commenting/feedback/support on the asset (social interaction). If I'm not mistaken, right now all of this functionality is already available in a service like GitLab. I can walk through the rgo archives and start uploading the latest versions of assets that are licensed to allow me to do so and all of the points above will be covered through the existing infrastructure of GitLab. If we simply wanted to mirror the functionality of rgo as it existed before we had to freeze it, we can do just that (walking through the archives and uploading the assets into the GitLab instance). This would make the scripts available to users again and in some cases we can replicate the description posts from rgo as well. This technically _could_ be the end of the discussion. But... I know that Jehan has been thinking for some time about integrating some sort of asset installer from within GIMP. I love this idea and want to make sure that we organize content on any "Registry 2.0" idea in a way that supports this capability as well as possible. GIMP Asset Installer =============== There are some organizational ideas that we need to work through to best support this idea, I think. Initially, I had mentioned that I was going to refer to plug-ins/scripts/brushes/etc... as simply "assets" to be generic. An asset can be a single .scm file, multiple .scm files, files to compile a plugin, brushes, gradients, files to compile a gegl op, etc... [image: assets.png] [assets.png] https://gitlab.com/GIMP/GIMP-Scripts/raw/aced57ae1fda9b38ed300e074c6a6e3327395529/ideas/assets.png GIT REPO ======== There are two main thoughts concerning organization on a git infrastructure to support this. 1. A single organization/account that will contain a single git repo for _each_ asset. 2. A single repo that contains assets + references to external assets as well. Single Repo ----------------- My personal ideas are to use a single repo that would include all of the assets inside of it, as well as submodules of external repositories from their respective authors. Basically, #2 from above. (I should note that I personally _love_ the idea of one repository = one asset, but I am also pragmatic and realize that this may get unwieldy very quickly. I do still wish it could be that way, though... ). [image: repo-full.png] [repo-full.png] https://gitlab.com/GIMP/GIMP-Scripts/raw/master/ideas/repo-full.png The repository can contain assets inside of it as well as submodules. The submodules themselves can either be a singular repository with assets, or repository with multiple assets contained inside. Importantly, the submodule can be a completely different git repository owned by someone else (and is basically it's own git repo with logs, etc...). So, in this approach, the "Registry 2.0" repo by itself can contain: 1. Assets 2. Submodules a. Single repository of an asset b. Single repository of multiple assets (not necessarily owned by us) (I also just realized that this idea could be considered a _super_set of what Jehan wants in single repo = single asset). The important thing for supporting an installer in the future is a way to enumerate the list of available assets contained inside the repo. I was personally thinking some sort of "Asset Index" file to point to all of the relevant assets for automation. [1] What's nice about this approach is that we can house assets ourselves in the main repo, house assets in other repos ourselves, or we can link in other authors assets as submodules. Single Account ---------------------- The approach as I understand it from Jehan for a single repository = single asset would look something like this: [image: account-full.png] [account-full.png] https://gitlab.com/GIMP/GIMP-Scripts/raw/master/ideas/account-full.png In this case, the account would contain multiple git repos, with 1:1 mapping between asset:repository. One of the problems I can see with this approach is: 1. A full git repo for a single .scm file seems like overkill? 2. Asset authors would _have_ to use our git repo (or would have to sync to them when they wanted to push something new). 3. Will we hit a limit to the number of repos allowed per account? (Not sure - can't find hard numbers on this at gitlab). [1] Asset Index ---------------------- Regardless of which approach is used, the main question is what type of index mechanism might have to be created to support an "Asset Installer" later. It may be possible to run a CI script that scrapes relevant data from the metadata of each asset in a standard formatted way to supply the relevant information for the installer? I'm honestly not 100% sure here and would welcome any feedback on the possibility or implementation. Implementation =========== At the moment there is a freeze on rgo. No new assets are being shared there. I can start walking through the archives now and begin the process of uploading the relevant information from assets that look like they might be worth the effort (with input from other folks that know about these things far better than I <cough>akk<cough>). Please, I am not on 100% firm footing with some of these ideas, I'm simply experimenting and reading docs to understand better what might be available to us, so don't hesitate to let me know if I'm off my rocker or completely off track on some of these thoughts. I think this is something worth meeting and discussing face-to-face at LGM as well, if everyone wanted to set aside a little bit of time to hash it out. -- Pat David https://pixls.us http://blog.patdavid.net _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
