Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org

[Pat David <patdavid gmail com>]

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