GNOME.org
 

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

Hi,

Just giving a few answers. I really can't make the time right now and
I think we will have to discuss this with voice, because it looks like
several things I say are really not understandable (well they are by
me, but my English may be lacking! At least I have to say the same
thing again).

On Mon, Apr 4, 2016 at 7:00 PM, Pat David <patdavid gmail com> wrote:

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... ).


Really I don't understand this point which Akkana is raising. Has
anyone ever made plugins for various software? I have, for a bunch,
many dead now, some still living. And never have I ever thought "oh
let's put all my completely unrelated plugins into the same
repository"! This is like the base of code organization, you just have
separate items. I have a bunch of repositories of my own, and have a
few dozens of repositories from various projects which I have needed
at some point.

I organized the repositories, some on my personal computer (the ones
which I code with the most often, or which I am working with lately),
some on a server (the ones which I don't code with often, or not
lately). And really, I have absolutely no problem with such an
organization. 0, NULL, nada!

Why is it hard to consider that 2 different software are better in
different repositories rather than in the same. You can still have
subdirectories locally on your computer to organize. But don't bring
your personal organization into the source code!
And yeah maybe some plugins are just a single file. So what? That does
not make it any more useless. If it is a good plugin, it is a good
plugin by himself. No need to absolutely want to fill in.

Now that is just my personal opinion on the matter, and I did not want
to bring it in anyway but in the end, after reading this a few times
here or on IRC, I could not stop myself. Why didn't I not want to give
my opinion? Because it does not matter! I said it 10 times. If you
want to have all your plugins in a single repository, no matter how
different they are, you can still do it on your github, gitlab or
whatever-else account. Just upload individual archives in the end. Or
even just make it a collection of scripts and tell users that this is
a all-or-nothing plugin.

But someone's organization should not change the fact that for the
service, 1 asset is 1 asset. This is a single item which will be
downloaded as a single asset by the user, be it composed of 1 or a
1000 files.

I am not going to ask Wordpress if I could not have all my Wordpress
plugins into a single repository because it is easier for me and that
I don't like the concept of 1 repository per plugin.

Now I will contradict myself: I actually have 2 such repositories, one
for various bash scripts which I don't feel like making into their own
repositories indeed, and the other one with a few (less than Akkana
even) GIMP scripts. So yes, I actually even contradicted myself on
this very topic of GIMP scripts! But the point is that these shell
scripts or GIMP plugins are only for my personal use right now. I
actually call them with stupid names like "jehan-scripts" or
something. But that's because I have not been making them available to
the world and I don't have access to a GIMP service whose main goal
was to manage GIMP plugins!
If there were such a server, dedicated to GIMP scripts, I would just
separate the repository into what make sense as individual plugins.
Because that's for public consumption, not just for me, and because
nobody will install "Jehan's scripts" with several unrelated scripts,
but they may install a plugin with a clear title and providing a given
useful feature.

So I completely see where you come from Akkana. And I agree. If you
are hosting on github, I'd likely do the same as you, and would make
some scripts to generate various tarballs for release.

But here we are speaking of a GIMP-dedicated hosting server which
provides you with as many repositories as you want (provided they are
GIMP plugins, of course!). Doesn't that make sense to just have a
clear conceptual separation?


[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?


Why? Do we absolutely need to fill emptiness? :-)


2. Asset authors would _have_ to use our git repo (or would have to sync to
them when they wanted to push something new).


No. As I said, the base of the base, the first feature of any plugin
system is: uploading tarball/zip archives of the plugin. No plugin
system should force the developer to use a specific repository. Maybe
you don't even want to use git at all! Who are we to judge?
Wordpress provides source repository to plugin developers, but you can
always just upload a zip when you want to make a release. Most other
plugin system work only like this (last I checked, I don't think that
Mozilla provides any kind of code repository to plugin developers).

The source code repository should be a bonus. It should not be the
main feature. This is what I said in my previous email already.

So no, you don't have to sync your repo. If you want to host it
somewhere else, just fine. Absolutely no problem with me. Just upload
archives when you want to make a release. This has not stopped dozens
of software out there to have thousands of plugins. Everybody knows
how to upload a file.


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).


Since we would be using our own gitlab, how could we be hitting an
account limit (we would set these ourselves)? Unless these are limits
in the code, which are usually int type limit, but then if we reach
such limit, there are probably more problems than reaching account
limits. I don't think there are any person out there who will write
thousands of plugins for GIMP single-handedly. :-)


[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.


This is absolutely not a problem. Have you had a look at software
management system on Linux? Well what we will do will be the same. We
will simply have a database of plugin information (this database is
usually in the form of a single file for package management systems,
which you download before showing the list of available software)
which can be requested by GIMP, when the user wants to see the list of
available plugins.
Since such a database can be updated close to real-time, the user
always have close to current information.
Here for instance, here is what looks like a Fedora repository:
http://mirrors.ircam.fr/pub/fedora/linux/releases/23/Everything/x86_64/os/
Inside repodata/, you've got the database files of everything which is
in the repository. It gives you the name, descriptions, etc.
everything about packages and where to download them. The Fedora
package management system would simply download these information
(that takes just a few seconds) to be able to present available
software to the user.

An alternative could be some kind of web API, but this could be a
little more resource-hungry than the previous system (you are
constantly querying the server, but on the other side you are asking
for less information, so less wait. It may be a better user experience
actually), which is likely why package management system don't go that
way. This is a possibility though, and actually I have been
considering it seriously.

As for the format of the metadata, that's not much of a problem
either. I even have a few sample somewhere of what could be the
metadata file for a GIMP plugin, as well as some files listing
contents of such a metadata file. The point is that there are many
good plugin systems out there, and we can just look at them. The
format itself is just a matter of choosing one format and sticking to
it.
Then we have to choose what data goes in. But this is not that hard either.

In any case, no these are not a problem at all, and only of technical
matter. This is the easy part.


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.


Yes. In any case, I think this will be my last message on this topic
before LGM. I have too many things to take care about first.

Thanks.

Jehan


--
Pat David
https://pixls.us
http://blog.patdavid.net
_______________________________________________
gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list




-- 
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]