An asset manager is undoubtedly something needed very badly -

There are some features that would be needed - which Jehan summarized quite well in an e-mail sent about 2 years ago (I remember the date because I was just back from Leipzig)

At first, I think requiring all assets to be in a git repository (git uses URLs - no need
to require a specific provider) - would itself be overkill. So maybe, just make content
'uploadable" might be enough. On the other hand, gitlab might provide ownership and content meta-information in a way we would not need to care about them -
just a system for one to enter a git (gitlab) URL and branch name - maybe requiring certain information to be in the repository.

Curation of assets remains one of the hardest points - it might be a _lot_ of _boring_ work -
and even somewhat dangerous - but still, I can imagine 2 categories of assets - one endorsed by the "GIMP team" - - i.e. curated - with no dangerous scripts/plug-ins,
and a "watch yourself" mode in which anything could be downloadable.

Either way- wathever is designed to register GIMO assets server side, a Python program can be made, to
run as a GIMP plug-in, that would provide a search, download and install interface for things
registered on the server side. This program is not a huge thing to do and would effectively provide GIMP
with its own "asset-store".

Anyway - just to get the ball rolling - I suppose this could be a topic with its own BoF session in London

On 1 April 2016 at 17:32, Pat David wrote:

Continuing on some discussions from irc...

Registry.gimp.org is down for the count.

I was thinking recently about some ideas for a possible replacement. Mostly thinking along the lines of what made the registry work well for folks.

In the rest of this email, I'll use the term "asset(s)" to refer to things like plug-ins, scripts, or brushes/gradients/curves/other assets.

Some essential functionality based on the old registry drupal instance:

1. Upload/Download assets for GIMP. 2. Describe the asset (usually by the uploader). 3. Comment on the assets.

This was handled previously by using drupal, which treated each entry as a post/node that included the ability to upload files, write about the files as a post, and had comment threads below it.

Keeping this functionality would be good, I think. The ability to post an asset is a given, but the ability to interact around it helps foster the community (and provides nice feedback for the authors).

From those thoughts, what would be nice to have in a replacement:

1. Provide at least the same previous functionality (as listed above). 2. Managed or easier to manage and keep updated. 3. Easier account management.
4. Collaborative environment for shared assets 5. Support possible GIMP integration in the future (one-click asset install?).

GitLab?
======

Initially, I had thought Github might be a good option for this but given its closed-source nature decided to investigate something like GitLab instead.

I like this idea personally due to some nice infrastructure:

1. The service is hosted + managed (and available as Free Software just in case we felt we needed to break out and host it ourselves). 2. The service integrates OAuth sign-in using a few different account types (lowers barrier to entry to participate). a. they use accounts, Google, Twitter, Github, or bitbucket accounts for sign-in.
3. Projects maintain all the git-goodness for control and tracking 4. Projects created as a git project can have a full description/README along with issue tracking integrated in the site

So, we can fulfill the original registry functionality and get the added benefit of a git infrastructure for those wanting to contribute, user accounts using OAuth to make it easy to participate, and the ability to do some interesting things (git submodules).

In speaking with Jehan about this, we should also consider what might be needed to support the ability to install assets from within GIMP in the future easily.

Organization
=========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

I'd like some input on what would make the most sense or work best for possible organization of repos.

I was also thinking that we could include some simple metadata in both any script files and the README.md files as a means to possibly help parsing relevant information for automated inclusion at a later date (GIMP plug-ins installer type of idea).

Curation ======

Initially I was thinking that curating the scripts for inclusion would be important. It's certainly possible for a smaller subset of all of the available scripts from the registry now to pick out ones that we use and check that they're not malicious and properly tagged/included. For instance, there's a handful of scripts that I personally find myself using often and can help validate/curate for inclusion. I don't mind doing more as needed.

I just wanted to get a discussion started about how we might consider moving forward on something like this. I think the scripts/plug-ins are important enough to users that it would be good to try and get something up and running soon.

I have started experimenting with including submodules from other author repos and how it might look here:

https://gitlab.com/GIMP/GIMP-Scripts/tree/master

I look forward to hearing some thoughts on this!

pat --
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

I personally am a huge supporter of redoing the registry, and I like the ideas you've proposed here. My only concern is one that was actually brought up by someone else a few months ago; registry integration within GIMP and the possibility of viruses.

I don't quite remember who mentioned it, but they brought up that registry integration within GIMP itself could potentially open the doors to viruses unless a virus detection feature was built into GIMP as well. Now, I'm not entirely sure how true this is but I would like to hear a final say on this whether this is an actual issue or not.

If it is an issue, what would be the best way to handle it? I'd imagine that building virus scanning within GIMP would take quite a long time and be pretty impractical. As such, I would suggest that we go with a self hosted solution so that we could incorporate a virus scanner on there to scan all the uploaded assets. Either that, or a hosted solution like GitLab that come with a virus scanning option along with it.

Again, not sure how much of an issue this even is. Just a thought.

- Kasim Ahmić

Sent from my iPhone

On Apr 1, 2016, at 4:32 PM, Pat David wrote:

Continuing on some discussions from irc...

Registry.gimp.org is down for the count.

I was thinking recently about some ideas for a possible replacement. Mostly thinking along the lines of what made the registry work well for folks.

In the rest of this email, I'll use the term "asset(s)" to refer to things like plug-ins, scripts, or brushes/gradients/curves/other assets.

Some essential functionality based on the old registry drupal instance:

1. Upload/Download assets for GIMP. 2. Describe the asset (usually by the uploader). 3. Comment on the assets.

This was handled previously by using drupal, which treated each entry as a post/node that included the ability to upload files, write about the files as a post, and had comment threads below it.

Keeping this functionality would be good, I think. The ability to post an asset is a given, but the ability to interact around it helps foster the community (and provides nice feedback for the authors).

From those thoughts, what would be nice to have in a replacement:

1. Provide at least the same previous functionality (as listed above). 2. Managed or easier to manage and keep updated. 3. Easier account management.
4. Collaborative environment for shared assets 5. Support possible GIMP integration in the future (one-click asset install?).

GitLab?
======

Initially, I had thought Github might be a good option for this but given its closed-source nature decided to investigate something like GitLab instead.

I like this idea personally due to some nice infrastructure:

1. The service is hosted + managed (and available as Free Software just in case we felt we needed to break out and host it ourselves). 2. The service integrates OAuth sign-in using a few different account types (lowers barrier to entry to participate). a. they use accounts, Google, Twitter, Github, or bitbucket accounts for sign-in.
3. Projects maintain all the git-goodness for control and tracking 4. Projects created as a git project can have a full description/README along with issue tracking integrated in the site

So, we can fulfill the original registry functionality and get the added benefit of a git infrastructure for those wanting to contribute, user accounts using OAuth to make it easy to participate, and the ability to do some interesting things (git submodules).

In speaking with Jehan about this, we should also consider what might be needed to support the ability to install assets from within GIMP in the future easily.

Organization
=========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

I'd like some input on what would make the most sense or work best for possible organization of repos.

I was also thinking that we could include some simple metadata in both any script files and the README.md files as a means to possibly help parsing relevant information for automated inclusion at a later date (GIMP plug-ins installer type of idea).

Curation ======

Initially I was thinking that curating the scripts for inclusion would be important. It's certainly possible for a smaller subset of all of the available scripts from the registry now to pick out ones that we use and check that they're not malicious and properly tagged/included. For instance, there's a handful of scripts that I personally find myself using often and can help validate/curate for inclusion. I don't mind doing more as needed.

I just wanted to get a discussion started about how we might consider moving forward on something like this. I think the scripts/plug-ins are important enough to users that it would be good to try and get something up and running soon.

I have started experimenting with including submodules from other author repos and how it might look here:

https://gitlab.com/GIMP/GIMP-Scripts/tree/master

I look forward to hearing some thoughts on this!

pat --
Pat David
https://pixls.us
http://blog.patdavid.net
_______________________________________________ gimp-web-list mailing list
gimp-web-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-web-list

I rather like GitLab, and this seems like at least as good a solution for a plugin registry as any other solution we've considered so far.

In fact, I think GitLab (or some similar solution) would also be a major improvement for tracking the core GIMP software. As an occasional contributor just to the documentation, I find Bugzilla, and the process of creating and uploading patch files, cumbersome and weirdly old-fashioned. GitLab could do everything Bugzilla or cgit can, and much more, _and_ it's got a much better UI and workflow.

~Andrew

On 2016-04-01 13:32, Pat David wrote:

Continuing on some discussions from irc...

Registry.gimp.org is down for the count.

I was thinking recently about some ideas for a possible replacement. Mostly thinking along the lines of what made the registry work well for folks.

In the rest of this email, I'll use the term "asset(s)" to refer to things like plug-ins, scripts, or brushes/gradients/curves/other assets.

Some essential functionality based on the old registry drupal instance:

1. Upload/Download assets for GIMP. 2. Describe the asset (usually by the uploader). 3. Comment on the assets.

This was handled previously by using drupal, which treated each entry as a post/node that included the ability to upload files, write about the files as a post, and had comment threads below it.

Keeping this functionality would be good, I think. The ability to post an asset is a given, but the ability to interact around it helps foster the community (and provides nice feedback for the authors).

From those thoughts, what would be nice to have in a replacement:

1. Provide at least the same previous functionality (as listed above). 2. Managed or easier to manage and keep updated. 3. Easier account management.
4. Collaborative environment for shared assets 5. Support possible GIMP integration in the future (one-click asset install?).

GitLab?
======

Initially, I had thought Github might be a good option for this but given its closed-source nature decided to investigate something like GitLab instead.

I like this idea personally due to some nice infrastructure:

1. The service is hosted + managed (and available as Free Software just in case we felt we needed to break out and host it ourselves). 2. The service integrates OAuth sign-in using a few different account types (lowers barrier to entry to participate). a. they use accounts, Google, Twitter, Github, or bitbucket accounts for sign-in.
3. Projects maintain all the git-goodness for control and tracking 4. Projects created as a git project can have a full description/README along with issue tracking integrated in the site

So, we can fulfill the original registry functionality and get the added benefit of a git infrastructure for those wanting to contribute, user accounts using OAuth to make it easy to participate, and the ability to do some interesting things (git submodules).

In speaking with Jehan about this, we should also consider what might be needed to support the ability to install assets from within GIMP in the future easily.

Organization
=========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

I'd like some input on what would make the most sense or work best for possible organization of repos.

I was also thinking that we could include some simple metadata in both any script files and the README.md files as a means to possibly help parsing relevant information for automated inclusion at a later date (GIMP plug-ins installer type of idea).

Curation ======

Initially I was thinking that curating the scripts for inclusion would be important. It's certainly possible for a smaller subset of all of the available scripts from the registry now to pick out ones that we use and check that they're not malicious and properly tagged/included. For instance, there's a handful of scripts that I personally find myself using often and can help validate/curate for inclusion. I don't mind doing more as needed.

I just wanted to get a discussion started about how we might consider moving forward on something like this. I think the scripts/plug-ins are important enough to users that it would be good to try and get something up and running soon.

I have started experimenting with including submodules from other author repos and how it might look here:

https://gitlab.com/GIMP/GIMP-Scripts/tree/master [1]

I look forward to hearing some thoughts on this!

pat

Links:
------
[1] https://gitlab.com/GIMP/GIMP-Scripts/tree/master

On 1 April 2016 at 18:14, Kasim Ahmic wrote:

I personally am a huge supporter of redoing the registry, and I like the ideas you've proposed here. My only concern is one that was actually brought up by someone else a few months ago; registry integration within GIMP and the possibility of viruses.

I don't quite remember who mentioned it, but they brought up that registry integration within GIMP itself could potentially open the doors to viruses unless a virus detection feature was built into GIMP as well. Now, I'm not entirely sure how true this is but I would like to hear a final say on this whether this is an actual issue or not.

If it is an issue, what would be the best way to handle it? I'd imagine that building virus scanning within GIMP would take quite a long time and be pretty impractical. As such, I would suggest that we go with a self hosted solution so that we could incorporate a virus scanner on there to scan all the uploaded assets. Either that, or a hosted solution like GitLab that come with a virus scanning option along with it.

Again, not sure how much of an issue this even is. Just a thought.

So - this would be one of the main purposes of a "curation" - Only non-malicious assets would be made available as "safe" from the server-side.
Having security features on the client side (i.e. on the computer of the person running GIMP), is
not feasible: one single line of code in a rogue plug-in can wipe the user harddrive.
. Assuring assets are safe, even if few, and can't be maliciously modified, in the repository is hard enough - but can be done.

The hard-to-balance thing is allowing publication of assets by a large amount of people, and having process/volunteers to ensure these assets are safe. Either way, I think the download and install should be done with a few clicks from wthin GIMP itself - we don't have to burden users to locate the file in a browser, download it, copy it to the right folder, set its file properties if that is not needed. If the assets represent a danger, they will represent an equal danger in this "manual way".

- Kasim Ahmić

Sent from my iPhone

On Apr 1, 2016, at 4:32 PM, Pat David wrote:

Continuing on some discussions from irc...

Registry.gimp.org is down for the count.

I was thinking recently about some ideas for a possible replacement. Mostly thinking along the lines of what made the registry work well for folks.

In the rest of this email, I'll use the term "asset(s)" to refer to things like plug-ins, scripts, or brushes/gradients/curves/other assets.

Some essential functionality based on the old registry drupal instance:

1. Upload/Download assets for GIMP. 2. Describe the asset (usually by the uploader). 3. Comment on the assets.

This was handled previously by using drupal, which treated each entry as a post/node that included the ability to upload files, write about the files as a post, and had comment threads below it.

Keeping this functionality would be good, I think. The ability to post an asset is a given, but the ability to interact around it helps foster the community (and provides nice feedback for the authors).

From those thoughts, what would be nice to have in a replacement:

1. Provide at least the same previous functionality (as listed above). 2. Managed or easier to manage and keep updated. 3. Easier account management.
4. Collaborative environment for shared assets 5. Support possible GIMP integration in the future (one-click asset install?).

GitLab?
======

Initially, I had thought Github might be a good option for this but given its closed-source nature decided to investigate something like GitLab instead.

I like this idea personally due to some nice infrastructure:

1. The service is hosted + managed (and available as Free Software just in case we felt we needed to break out and host it ourselves). 2. The service integrates OAuth sign-in using a few different account types (lowers barrier to entry to participate). a. they use accounts, Google, Twitter, Github, or bitbucket accounts for sign-in.
3. Projects maintain all the git-goodness for control and tracking 4. Projects created as a git project can have a full description/README along with issue tracking integrated in the site

So, we can fulfill the original registry functionality and get the added benefit of a git infrastructure for those wanting to contribute, user accounts using OAuth to make it easy to participate, and the ability to do some interesting things (git submodules).

In speaking with Jehan about this, we should also consider what might be needed to support the ability to install assets from within GIMP in the future easily.

Organization
=========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

I'd like some input on what would make the most sense or work best for possible organization of repos.

I was also thinking that we could include some simple metadata in both any script files and the README.md files as a means to possibly help parsing relevant information for automated inclusion at a later date (GIMP plug-ins installer type of idea).

Curation ======

Initially I was thinking that curating the scripts for inclusion would be important. It's certainly possible for a smaller subset of all of the available scripts from the registry now to pick out ones that we use and check that they're not malicious and properly tagged/included. For instance, there's a handful of scripts that I personally find myself using often and can help validate/curate for inclusion. I don't mind doing more as needed.

I just wanted to get a discussion started about how we might consider moving forward on something like this. I think the scripts/plug-ins are important enough to users that it would be good to try and get something up and running soon.

I have started experimenting with including submodules from other author repos and how it might look here:

https://gitlab.com/GIMP/GIMP-Scripts/tree/master

I look forward to hearing some thoughts on this!

pat --
Pat David
https://pixls.us
http://blog.patdavid.net
_______________________________________________ gimp-web-list mailing list
gimp-web-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-web-list

_______________________________________________ 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

On 2016-04-01 13:32, Pat David wrote:

Organization =========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

Whether or not we can get plugin developers to follow it, separating scripts and plugins into different repositories seems like a good recommendation, for a number of reasons. For plugin and script authors, it would make managing bugs and user feedback easier. For end users, it's also annoying to clone a large repository when you're only interested in a small subset of its contents. If authors are really going to lump together their plugins and scripts, we could at least recommend that they try to only group together the things that are most closely related. Create several smaller collections of scripts, instead of one giant collection.

Hi,

On Fri, Apr 1, 2016 at 11:41 PM, Andrew Toskin wrote:

I rather like GitLab, and this seems like at least as good a solution for a plugin registry as any other solution we've considered so far.

In fact, I think GitLab (or some similar solution) would also be a major improvement for tracking the core GIMP software. As an occasional contributor just to the documentation, I find Bugzilla, and the process of creating and uploading patch files, cumbersome and weirdly old-fashioned. GitLab could do everything Bugzilla or cgit can, and much more, _and_ it's got a much better UI and workflow.

The discussion is not about core GIMP and I don't think there are any advantages in migrating GIMP out of GNOME infrastructure. I mean, if there were several long-term contributors willing to maintain our own infrastructure, and which we can trust to not disappear in a few months, why not. And even so, I'm not sure what would be the gain there. Bugzilla works very well, in my opinion. The patch process is like 100x better than the weird fork logics that github imposes. And I don't see anything in the web UI that I can't do 1000x better in my terminal.

Anyway this thread is about plugins and since there is nearly no chance for GIMP migrating to a gitlab hosting, let's not diverge the topic.
Thanks.

Jehan

~Andrew

On 2016-04-01 13:32, Pat David wrote:

Continuing on some discussions from irc...

Registry.gimp.org is down for the count.

I was thinking recently about some ideas for a possible replacement. Mostly thinking along the lines of what made the registry work well for folks.

In the rest of this email, I'll use the term "asset(s)" to refer to things like plug-ins, scripts, or brushes/gradients/curves/other assets.

Some essential functionality based on the old registry drupal instance:

1. Upload/Download assets for GIMP. 2. Describe the asset (usually by the uploader). 3. Comment on the assets.

This was handled previously by using drupal, which treated each entry as a post/node that included the ability to upload files, write about the files as a post, and had comment threads below it.

Keeping this functionality would be good, I think. The ability to post an asset is a given, but the ability to interact around it helps foster the community (and provides nice feedback for the authors).

From those thoughts, what would be nice to have in a replacement:

1. Provide at least the same previous functionality (as listed above). 2. Managed or easier to manage and keep updated. 3. Easier account management.
4. Collaborative environment for shared assets 5. Support possible GIMP integration in the future (one-click asset install?).

GitLab?
======

Initially, I had thought Github might be a good option for this but given its closed-source nature decided to investigate something like GitLab instead.

I like this idea personally due to some nice infrastructure:

1. The service is hosted + managed (and available as Free Software just in case we felt we needed to break out and host it ourselves). 2. The service integrates OAuth sign-in using a few different account types (lowers barrier to entry to participate). a. they use accounts, Google, Twitter, Github, or bitbucket accounts for sign-in.
3. Projects maintain all the git-goodness for control and tracking 4. Projects created as a git project can have a full description/README along with issue tracking integrated in the site

So, we can fulfill the original registry functionality and get the added benefit of a git infrastructure for those wanting to contribute, user accounts using OAuth to make it easy to participate, and the ability to do some interesting things (git submodules).

In speaking with Jehan about this, we should also consider what might be needed to support the ability to install assets from within GIMP in the future easily.

Organization
=========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

I'd like some input on what would make the most sense or work best for possible organization of repos.

I was also thinking that we could include some simple metadata in both any script files and the README.md files as a means to possibly help parsing relevant information for automated inclusion at a later date (GIMP plug-ins installer type of idea).

Curation ======

Initially I was thinking that curating the scripts for inclusion would be important. It's certainly possible for a smaller subset of all of the available scripts from the registry now to pick out ones that we use and check that they're not malicious and properly tagged/included. For instance, there's a handful of scripts that I personally find myself using often and can help validate/curate for inclusion. I don't mind doing more as needed.

I just wanted to get a discussion started about how we might consider moving forward on something like this. I think the scripts/plug-ins are important enough to users that it would be good to try and get something up and running soon.

I have started experimenting with including submodules from other author repos and how it might look here:

https://gitlab.com/GIMP/GIMP-Scripts/tree/master [1]

I look forward to hearing some thoughts on this!

pat

Links:
------
[1] https://gitlab.com/GIMP/GIMP-Scripts/tree/master _______________________________________________ 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

Hello,

On Fri, Apr 1, 2016 at 10:52 PM, Joao S. O. Bueno wrote:

An asset manager is undoubtedly something needed very badly -

There are some features that would be needed - which Jehan summarized quite well in an e-mail sent about 2 years ago (I remember the date because I was just back from Leipzig)

Yes, as you remind, plugin management is indeed a topic I have thought about for several years now. I wrote/draw many pages of UI, code and infrastructure design about the topic. Unfortunately I never came to write much of the actual code. I hope I can make time soon, but it really depends how will go my current project (ZeMarmot).

At first, I think requiring all assets to be in a git repository (git uses URLs - no need
to require a specific provider) - would itself be overkill. So maybe, just make content
'uploadable" might be enough. On the other hand, gitlab might provide ownership and content meta-information in a way we would not need to care about them -
just a system for one to enter a git (gitlab) URL and branch name - maybe requiring certain information to be in the repository.

In my original design, a plugin developer would have the choice to either upload archives for new releases (leaving them the possibility to host wherever one want), or optionally to be hosted by the GIMP project. The idea behind tis second possibility came from my experience with Wordpress plugins. Wordpress offers a code repository to host plugins (SVN repository, since this is an old system from before git really becomes popular, but everything can be done with a git-based system). The webpage for the repository is automatically built from the README (similarly to github, and I suppose gitlab. They did not invent the concept).

And the very cool stuff was that you could release a new version of your plugin by tagging your repository (this too, github did not invent). So what would happen is that you tag your repository, and any wordpress in the world with this plugin would get a notification that there is an update available. From a developer point of view, this is cool because I really dislike having to fire up the web browser.

So when Patdavid proposed to use gitlab, I thought "oh why not, we could retarget gitlab to host our plugins".

I'm not going to write for too long, because I am tired and want to go to bed. And I'd like to discuss these things later at LGM. I really can't make the time these days for this.

Curation of assets remains one of the hardest points - it might be a _lot_ of _boring_ work -
and even somewhat dangerous - but still, I can imagine 2 categories of assets - one endorsed by the "GIMP team" - - i.e. curated - with no dangerous scripts/plug-ins,
and a "watch yourself" mode in which anything could be downloadable.

This is exactly what I said on IRC. I actually completely disagree about a fully curated system. I think it makes no sense. Firefox or Wordpress or any system with a huge plugin ecosystem never would have gone that far if their first idea had been to do a fully-curated system where only manually validated plugins could make it through to the users.

So yes, letting all, there will be a lot of crappy code, and even security risks. But there are ways to limit risks: automatic code audit, the eyes of many users (who can click a button "Dangerous content").

Moreover we don't have the manpower. I will say it immediately: I won't spend my time on plugin code checking! Will Patdavid and a few others be the ones validating everything? Quality but also code (for potential intentional backdoors or security leaks)?

But yes, as you say, I could completely see the advantage of some curation, with a list of plugins which have been audited. We could have monthly "Pick of the team" to promote some specific high quality/value plugins, etc. And we could have checkboxes to see only curated plugins. But there has to be a possibility to also see non curated plugins.

I don't want a system where only a limited set of people have upload rights.

Either way- wathever is designed to register GIMO assets server side, a Python program can be made, to
run as a GIMP plug-in, that would provide a search, download and install interface for things
registered on the server side. This program is not a huge thing to do and would effectively provide GIMP
with its own "asset-store".

Anyway - just to get the ball rolling - I suppose this could be a topic with its own BoF session in London

Definitely.

Jehan

On 1 April 2016 at 17:32, Pat David wrote:

Continuing on some discussions from irc...

Registry.gimp.org is down for the count.

I was thinking recently about some ideas for a possible replacement. Mostly thinking along the lines of what made the registry work well for folks.

In the rest of this email, I'll use the term "asset(s)" to refer to things like plug-ins, scripts, or brushes/gradients/curves/other assets.

Some essential functionality based on the old registry drupal instance:

1. Upload/Download assets for GIMP. 2. Describe the asset (usually by the uploader). 3. Comment on the assets.

This was handled previously by using drupal, which treated each entry as a post/node that included the ability to upload files, write about the files as a post, and had comment threads below it.

Keeping this functionality would be good, I think. The ability to post an asset is a given, but the ability to interact around it helps foster the community (and provides nice feedback for the authors).

From those thoughts, what would be nice to have in a replacement:

1. Provide at least the same previous functionality (as listed above). 2. Managed or easier to manage and keep updated. 3. Easier account management.
4. Collaborative environment for shared assets 5. Support possible GIMP integration in the future (one-click asset install?).

GitLab?
======

Initially, I had thought Github might be a good option for this but given its closed-source nature decided to investigate something like GitLab instead.

I like this idea personally due to some nice infrastructure:

1. The service is hosted + managed (and available as Free Software just in case we felt we needed to break out and host it ourselves). 2. The service integrates OAuth sign-in using a few different account types (lowers barrier to entry to participate). a. they use accounts, Google, Twitter, Github, or bitbucket accounts for sign-in.
3. Projects maintain all the git-goodness for control and tracking 4. Projects created as a git project can have a full description/README along with issue tracking integrated in the site

So, we can fulfill the original registry functionality and get the added benefit of a git infrastructure for those wanting to contribute, user accounts using OAuth to make it easy to participate, and the ability to do some interesting things (git submodules).

In speaking with Jehan about this, we should also consider what might be needed to support the ability to install assets from within GIMP in the future easily.

Organization
=========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

I'd like some input on what would make the most sense or work best for possible organization of repos.

I was also thinking that we could include some simple metadata in both any script files and the README.md files as a means to possibly help parsing relevant information for automated inclusion at a later date (GIMP plug-ins installer type of idea).

Curation ======

Initially I was thinking that curating the scripts for inclusion would be important. It's certainly possible for a smaller subset of all of the available scripts from the registry now to pick out ones that we use and check that they're not malicious and properly tagged/included. For instance, there's a handful of scripts that I personally find myself using often and can help validate/curate for inclusion. I don't mind doing more as needed.

I just wanted to get a discussion started about how we might consider moving forward on something like this. I think the scripts/plug-ins are important enough to users that it would be good to try and get something up and running soon.

I have started experimenting with including submodules from other author repos and how it might look here:

https://gitlab.com/GIMP/GIMP-Scripts/tree/master

I look forward to hearing some thoughts on this!

pat --
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

_______________________________________________ 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

Off the top of my head, three points of view on such a thing:

Admin; - good spam prevention (IP banning, lock on keywords, approval of first post...)
- malware prevention. This could be a trust system (but don't forget that even trustable persons could have their account hijacked). Reviewing SCM/PY is easy. Reviewing C is more complex, because we have to check that the binary is indeed matching the source we review, or we have to rebuild it (for all platforms...). - easy user management

Author: - decent registration procedure
- ease of publication (that goes a bit against security/spam, so a balance should be found)
- statistics (I'm a sucker for download stats, especially when they show me that my more popular scripts aren't the ones I think; so far nothing beats SourceForge...)
- ability to document things easily: formatting with markdown or BBCode, including support for images. Ability to upload text and images from my PC (v.s. editing in a web page) is a plus - communications with users: forum, etc. Mail notification necessary - ability to share/transmit ownership - I don't think this system should be a place to maintain/share the source code. We could however enforce a FOSS/CC discipline and require the source files to be provided (for some assets, this could mean the original XCF/SVG file...)
- Human-readable, permanent URL to homepage so that it can be posted on other sites

User:
- straightforward, no-questions-asked downloads - easy registration for forums
- semi-anonymous use of forums (guest mode without registration, but with some more hurdles such as captchas) - search capabilities

Hello,

On Sat, Apr 2, 2016 at 12:18 AM, Andrew Toskin wrote:

On 2016-04-01 13:32, Pat David wrote:

Organization =========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

Whether or not we can get plugin developers to follow it, separating scripts and plugins into different repositories seems like a good recommendation, for a number of reasons. For plugin and script authors, it would make managing bugs and user feedback easier. For end users, it's also annoying to clone a large repository when you're only interested in a small subset of its contents. If authors are really going to lump together their plugins and scripts, we could at least recommend that they try to only group together the things that are most closely related. Create several smaller collections of scripts, instead of one giant collection.

Exactly. Some people like to create huge collections of scripts. G'Mic comes to mind. They will obviously continue to do so anyway. I personally prefer to install only the scripts I need (and not 100 others which would come with). Well then some scripts are closely related and it would make sense to have these together. Why not. There are many cases.

In the end though, every content creator is free though. My point is not to enforce a style of plugin creation. The point was to make the equivalency: 1 repository = 1 extension. What I call "extension" here is a 1-time download item. It can be a python plugin, a GimpFu script, a collection of brushes, a theme or an icon theme, patterns, whatever which can be installed in GIMP. It can be 1 single script, as 100 scripts, or a mix of contents. Plugin developers are free to do whatever they want. They just have to know that 1 repo = 1 extension. So when a user clicks "Install", the user installs the whole extension, be it just 1 script or a whole collection of 1000 scripts.

In this repo, they would have a README in the root directory, which will be used to generate the extension description. I think this is much better than trying to develop a metadata format where a plugin developer would have to organize one's plugins in a complex subdirectory structure.

Of course, a plugin developer could always go the basic way: uploading an archive for new releases. I would imagine that developers who already have their own organization and their repository somewhere may prefer to keep this way.
The repository proposition is only meant as a bonus for plugin developers who would not know where to host their code. We could tell them: hey, just let us host your code if you want. Which will incidentally help for integration (releases could be done by tagging a commit, etc.).

Just wanted to make the idea clear.

Jehan

ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot

On 02/04/16 00:18, Andrew Toskin wrote:

Whether or not we can get plugin developers to follow it, separating scripts and plugins into different repositories seems like a good recommendation, for a number of reasons. For plugin and script authors, it would make managing bugs and user feedback easier. For end users, it's also annoying to clone a large repository when you're only interested in a small subset of its contents. If authors are really going to lump together their plugins and scripts, we could at least recommend that they try to only group together the things that are most closely related. Create several smaller collections of scripts, instead of one giant collection.

A single script file can register several separate scripts...

Am 03.04.2016 um 11:58 schrieb Ofnuts:

On 02/04/16 00:18, Andrew Toskin wrote:

Create several smaller collections of scripts, instead of one giant collection.

A single script file can register several separate scripts...

s/scripts/procedures/

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

Andrew Toskin writes:

On 2016-04-01 13:32, Pat David wrote: Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

Whether or not we can get plugin developers to follow it, separating scripts and plugins into different repositories seems like a good recommendation, for a number of reasons. For plugin and script authors, it would make managing bugs and user feedback easier.

It would make managing repositories much harder, though.

I currently have roughly 20 GIMP scripts and plug-ins in my gimp-plugins repository, and would want to share maybe 15 of them (some are silly and not worth sharing). Please don't force me to create 20 different repositories, most containing only a single python script. It clutters my github (or, I assume, gitlab) profile, assuming they'd even let me create that many repos; it makes it hard to keep multiple machines current since I have to cd into each of those repos and make sure they're in sync; and it's harder to set up (I have to do things like edit .git/config by hand in 20 repos instead of just one to do things like make pushurl !- url).

For end users,
it's also annoying to clone a large repository when you're only interested in a small subset of its contents.

That's true. But nobody's suggesting that end users would be cloning git repos, are they? They'd just be running some friendly UI to say "give me the files I need for the foo plugin", and the backend downloads the right files and puts them in the right place. End users will never know they're using git at all.

...Akkana

Just agreeing with a few of Ofnuts' points:

Ofnuts writes:

Author:
- communications with users: forum, etc. Mail notification necessary

+1. With the current setup, I remember going to a page I'd made for one of my plug-ins and discovering there was a question there from four years earlier that I'd had no idea about.

- ability to share/transmit ownership

Good one!

- I don't think this system should be a place to maintain/share the source code. We could however enforce a FOSS/CC discipline and require the source files to be provided (for some assets, this could mean the original XCF/SVG file...)

I like the experiments Pat has been doing with making links inside a repo that link to other repos. If the GIMP plugin repository can include files from a developer's site on github or wherever, that solves the problem of developers who are actively improving a plugin but forget that they also need to update the version on GIMP's repository.

User:
- straightforward, no-questions-asked downloads - easy registration for forums
- semi-anonymous use of forums (guest mode without registration, but with some more hurdles such as captchas)
- search capabilities

- browse capabilities, by category or keyword: browsing all the plugins in the color category isn't the same as searching for everything that has the word "color" anywhere in the description, a major problem with the previous plug-in repository. And maybe also by date: browse the recently added plugins.

...Akkana

Hi,

On Mon, Apr 4, 2016 at 2:50 AM, Akkana Peck wrote:

Andrew Toskin writes:

On 2016-04-01 13:32, Pat David wrote: Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

Whether or not we can get plugin developers to follow it, separating scripts and plugins into different repositories seems like a good recommendation, for a number of reasons. For plugin and script authors, it would make managing bugs and user feedback easier.

It would make managing repositories much harder, though.

I currently have roughly 20 GIMP scripts and plug-ins in my gimp-plugins repository, and would want to share maybe 15 of them (some are silly and not worth sharing). Please don't force me to create 20 different repositories, most containing only a single python script. It clutters my github (or, I assume, gitlab) profile,

When I read this, I understand that I am really not clear. The design I propose would not propose developers to host their code to github/github/any random git repository out there. We would have our own centralized system, say called extensions.gimp.org (or reusing registry.gimp.org, why not). This could be a gitlab instance (since patdavid proposed so. Looks like a goot idea), customized to our needs. And this would be made to host GIMP plugin/contents only (we could have git hooks checking contents on a `git push` and allowing only certain files so that it won't be possible to just push any random file).

So no, I am not saying and have never said that we would grab repository from "elsewhere". I know patdavid seemed to have such an idea at some point, but I thought we made the point clear on IRC. Having the possibility to register any repository out there, it immediately makes me think of OpenHub (openhub.net). For anyone using OpenHub, it is cool, but you probably also noticed that it is slow as hell (often to the point it is basically "down" from user viewpoint), and that repository information are usually late by days if not weeks. Of course one could assume they just don't have enough servers to handle the load, but what makes think that the GIMP project would be able to do what several companies have tried (OpenHub has been bought a few times. It used to be called Ohloh) and basically failed? A system as you propose means basically having to pull random repositories all the time to know what's new (most of them would probably never have anything new), and looping forever. So no, that's not and has never been what I am proposing. This design is a failure by nature.

Being a centralized system means:

- less load. We don't need to check for hundreds of user repository. We are just waiting for them to push. - reactive: a developer tags its master? Bam! New plugin release. It's available in GIMP installations out there. We can easily have git hooks checking for tags. A OpenHub-style system, you would wait days or weeks before you even see your plugin in GIMP. - more control over the contents and refusing whatever should not be part of a GIMP extension (again with git hooks), like random binaries. You can't control and forbid contents from a remote repository.

Conclusion: you won't have your github profile cluttered with dozens of new repository. You will have your extensions.gimp.org profile filled with as many repositories as you have extensions there. And that makes sense to me. If you were look at my Wordpress user page (they don't seem to have these in a public fashion, but whatever) or my pypi page (same), or whatever else, you will not see a single big project called "All of Jehan's code", no you would see a list of smaller projects with meaningful individual names.

assuming they'd even let me create that many repos; it makes it hard

So nobody asks you to make repos on github. But if you really insisted and did not want to host your code on extensions.gimp.org, then you could your single big repo on github or anywhere else, and just generate archives that you could upload for every release on extensions.gimp.org. Handling per-release tarball is a basic feature. Wordpress for instance also provide code repository, but developers are not forced to use them and can just release tarball at regular intervals.
Then you can do whatever you want to manage multiple extensions into a single repository.

to keep multiple machines current since I have to cd into each of those repos and make sure they're in sync; and it's harder to set up (I have to do things like edit .git/config by hand in 20 repos instead of just one to do things like make pushurl !- url).

Side note: saying you have to do this kind of stuff is exactly a perfect example of why github workflow basically broke a sane git workflow!

For end users,
it's also annoying to clone a large repository when you're only interested in a small subset of its contents.

That's true. But nobody's suggesting that end users would be cloning git repos, are they? They'd just be running some friendly UI to say "give me the files I need for the foo plugin", and the backend downloads the right files and puts them in the right place. End users will never know they're using git at all.

Indeed. End users won't even use git at all. We are not going to add git as a dependency for GIMP just to install plugins! Plugins will be downloaded (probably in https, a protocol which don't need additional dependency to be available everywhere).

The git discussion is only for developer side.

To be clear, I would never have started from this topic. This is already an optional feature (as said, the basic feature is just being able to upload a zip/tarball of your plugin). What really matters at first, is having a sane installation workflow and new extension format (not a complete new format. It would be based off what we have, but with additional metadata, to handle description, versionning, etc. I already have a sample of this — somewhere in my computer — that I had been working on more than a year ago, based off various other extension formats for other software out there).

Jehan

...Akkana
_______________________________________________ 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

Hi,

On Mon, Apr 4, 2016 at 3:00 AM, Akkana Peck wrote:

Just agreeing with a few of Ofnuts' points:

Ofnuts writes:

Author:
- communications with users: forum, etc. Mail notification necessary

+1. With the current setup, I remember going to a page I'd made for one of my plug-ins and discovering there was a question there from four years earlier that I'd had no idea about.

- ability to share/transmit ownership

Good one!

- I don't think this system should be a place to maintain/share the source code. We could however enforce a FOSS/CC discipline and require the source files to be provided (for some assets, this could mean the original XCF/SVG file...)

I like the experiments Pat has been doing with making links inside a repo that link to other repos. If the GIMP plugin repository can include files from a developer's site on github or wherever,

This experiment was about a perfectly hand-curated small set of plugins. I completely understand that this is also very interesting. But Pat does not need me to do this. If that is what people have in mind, I won't be onboard. Don't get me wrong. This is still very cool, I support the project and I could help from time to time. But this is not as high a priority for me as other things. And that's a completely different project to the one I am talking about.

I am talking about a plugin management system, with a user side (within GIMP, to be able to browse hundreds of plugins, install/uninstall them, automatic update when there are new versions…) and a developer side (a way to upload their plugins, which can be as basic as uploading a zip of their code, up to fancy GIMP-hosted repositories).
The curation is not contradictory to my idea and could be used within the bigger plugin management system (there could be a small set of GIMP team-maintained plugins, or team picks, and "approved" plugins, etc.), but this curation cannot be the technical base of the whole system.

Because no, using a central git repository with submodules to user-maintained repositories inside it is not scaling up! I don't see at all actually how submodules could be the base of anything for a plugin management system.

that solves the problem of developers who are actively improving a plugin but forget that they also need to update the version on GIMP's repository.

No, setting a submodule for a given third-party repository does not magically give you write access to this repository (and fortunately! uhuh). You'd still have to fork if you want to improve the code of a given repository when the original author is not responding. Once again, this is manual curation.

User:
- straightforward, no-questions-asked downloads - easy registration for forums
- semi-anonymous use of forums (guest mode without registration, but with some more hurdles such as captchas)

Why would we have forums? We are talking about a plugin system. We could have comments on plugins, why not. And *if: we decided to have a source hosting (gitlab or other), then obviously bug reports. But that's it.

Now if people want generic official forums (I know I don't, we already have mailing lists, enough for me), that's a completely different discussion.

- search capabilities

- browse capabilities, by category or keyword: browsing all the plugins in the color category isn't the same as searching for everything that has the word "color" anywhere in the description, a major problem with the previous plug-in repository. And maybe also by date: browse the recently added plugins.

I agree with most features above. But just to make things clear: we can't have all this for a first release. But yes this kind of things have to be prepared from the extension format (with keywords, and categories/tags for instance).

Also let's not compare with the old registry. This was just a glorified do-it-all website where anyone could just upload anything, with basically no failsafe whatsoever. This had never been thought as a plugin system, but was only a generic hosting system (Drupal if not mistaken). In my opinion, there is basically *nothing* to be used from the old system.

If you want to compare, please let's compare with good existing plugin directories out there (Firefox, Wordpress, whatever has a huge base of plugins) and try to see what works and what does not work well for them. Let's work with good examples.

Jehan

...Akkana
_______________________________________________ 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

Gesendet: Montag, 04. April 2016 um 12:03 Uhr Von: "Jehan Pagès"

When I read this, I understand that I am really not clear.

So no, I am not saying and have never said that we would grab repository from "elsewhere". I know patdavid seemed to have such an idea at some point, but I thought we made the point clear on IRC.

It looks like you went out of that IRC meeting with an different impression than I.

What I remember from the meeting:

- a repository or repositories *on gitlab.com* to host all of the official, curated resources - encouraging other developers to use Git (on github, gitlab, savannah, ...) as well, and possibly add their repositories as submodules/subtrees (with technical details to be filled in by people who know about git than me) - use gitlab.com as opposed to github to be able to (if the need arises, for example gitlab turning evil) host an instance ourselves and migrate everything there

I am also still puzzled how the "one repository per 'script/plugin'" (we really need a better term for that concept) approach will be managed.

Maybe this is a good time to remind everyone that Wilber, our IRC bot, has the Meetbot plugin installed: http://meetbot.debian.net/Manual.html

Using it more frequently would make even small, rather informal meetings with all of their action items, agreements and disagreements easier to record.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

Hi,

On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher wrote:

Gesendet: Montag, 04. April 2016 um 12:03 Uhr Von: "Jehan Pagès"

When I read this, I understand that I am really not clear.

So no, I am not saying and have never said that we would grab repository from "elsewhere". I know patdavid seemed to have such an idea at some point, but I thought we made the point clear on IRC.

It looks like you went out of that IRC meeting with an different impression than I.

What I remember from the meeting:

- a repository or repositories *on gitlab.com* to host all of the official, curated resources - encouraging other developers to use Git (on github, gitlab, savannah, ...) as well, and possibly add their repositories as submodules/subtrees (with technical details to be filled in by people who know about git than me) - use gitlab.com as opposed to github to be able to (if the need arises, for example gitlab turning evil) host an instance ourselves and migrate everything there

In any cases, we should not go the road of syncing with repositories of third-party services (neither github nor gitlab, nor whatever). I think this is just a road to hell. With time passing and hundreds and hundreds of plugins. And there would be no control over their contents, and so on.

For me, this is better to just stick to tarball plugins if we cannot host our own controlled repository service.

I am also still puzzled how the "one repository per 'script/plugin'" (we really need a better term for that concept) approach will be managed.

Let's call them "extensions" for the time being (since we already use the term "plugin" and "scripts", but I don't think we use the term "extension" yet). Anyway the point is to have a single page for a single extension. If you want to go to the page for a Firefox extension, you don't get a page of all the extensions made by this particular developer (or team). You get the description for this one extension. This is the same. One single extension gets one page (and one single repository, and one single bug tracker, and so on). It does not share with other extensions (same developer or not).

This is the whole conceptual point: each extension is separate.

Now I repeat: an extension can be a whole collection of scripts or plugins. If all your scripts make sense together, and you want users to install them all at once, that's possible. You still have one single extension (with a single page, a single repo…), simply it has 10 or maybe why not 100 scripts inside (which themselves may register several procedures each, as you noted earlier).

So that's simple: - if you conceptually associate your scripts/plugins/resources like being part of the same thing, then you have them all in a single repository and they are distributed as a single extension. - else if you conceptually consider these scripts/plugins/resources like being different unrelated items (they just happen to all be made by the same developer. Other than this, there is no reason to install them together), they are different extensions. As a consequence, they are in different repositories.

Jehan

Maybe this is a good time to remind everyone that Wilber, our IRC bot, has the Meetbot plugin installed: http://meetbot.debian.net/Manual.html

Using it more frequently would make even small, rather informal meetings with all of their action items, agreements and disagreements easier to record.

-- Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD _______________________________________________ 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

Gesendet: Montag, 04. April 2016 um 15:48 Uhr Von: "Jehan Pagès"

On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher wrote:

I am also still puzzled how the "one repository per 'script/plugin'" (we really need a better term for that concept) approach will be managed.

Let's call them "extensions" for the time being (since we already use the term "plugin" and "scripts", but I don't think we use the term "extension" yet).

We do, and it has a very specific meaning - for example, Script-Fu is a GIMP_EXTENSION.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

On Mon, Apr 4, 2016 at 4:04 PM, Michael Schumacher wrote:

Gesendet: Montag, 04. April 2016 um 15:48 Uhr Von: "Jehan Pagès"

On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher wrote:

I am also still puzzled how the "one repository per 'script/plugin'" (we really need a better term for that concept) approach will be managed.

Let's call them "extensions" for the time being (since we already use the term "plugin" and "scripts", but I don't think we use the term "extension" yet).

We do, and it has a very specific meaning - for example, Script-Fu is a GIMP_EXTENSION.

Right. I forgot about this.

Jehan

--
Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

_______________________________________________ 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

At the risk of putting words into Pat's mouth, wasn't he referring to them as assets?

Kevin

From: gimp-developer-list  on behalf of Jehan Pags 
Sent: 04 April 2016 15:19
To: Michael Schumacher
Cc: gimp-web-list; GIMP Developer List
Subject: Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for    registry.gimp.org

On Mon, Apr 4, 2016 at 4:04 PM, Michael Schumacher  wrote:
>> Gesendet: Montag, 04. April 2016 um 15:48 Uhr
>> Von: "Jehan Pags" 
>
>> On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher  wrote:
>
>> > I am also still puzzled how the "one repository per 'script/plugin'" (we really need a better term for that concept) approach will be managed.
>>
>> Let's call them "extensions" for the time being (since we already use
>> the term "plugin" and "scripts", but I don't think we use the term
>> "extension" yet).
>
> We do, and it has a very specific meaning - for example, Script-Fu is a GIMP_EXTENSION.

Right. I forgot about this.

Jehan

> --
> Regards,
> Michael
> GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
>
> _______________________________________________
> 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

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

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

Hi,

I didn't follow the whole discussion so I hope to not repeat things that were already said.

One problem of the current registry (before it was broken) is that there are compiled plug-ins for just one platform, e.g. Win32, if compiled at all.
Therefore users of other or newer platforms, e.g. OS X, either have to compile it on their own or simply can't use it. This is an overload to non-developing users. I thought it it's a good idea to provide plug-in builds for all relevant platform at a single, central address. Each asset should have it's own folder there, such as $hoster/gimp-registry/plug-ins/$plug-in This makes it easy for users as well as the asset browser and downloader component in GIMP to browse and find assets. I don't want to promise too much, but perhaps it could be integrated into our Jenkins CI system one day and then it's easier to generate jobs for the plug-in builds, too.

I'm not sure whether it's a good idea to rely on private Git hosting provider like Gitlab. If they started going the Sourceforge.net way we had to move again. Does the GNOME infrastructure deliver something appropriate, too?

Greetings

Sven

Jehan Pags writes:
[on one repo per asset vs. one repo containing many assets]

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.

In the current GIMP source tree, circuit.scm,clothify.scm, coffee.scm, line-nova.scm, old-photo.scm, spinning-globe.scm and spyrogimp.scm (I just picked a random set) are all completely unrelated scripts. Yet there they all are, 53 different .scm files in the GIMP source repository in the plug-ins/script-fu/scripts/ directory, and similar unrelated collections in plug-ins/pygimp/plug-ins/ and plug-ins/ itself.

You are arguing that it's easier/better to maintain unrelated assets each in its own repository. But evidently the GIMP development team agrees with me: they have and a bunch of unrelated script files together within one directory within one big repository. That's how I organize my GIMP plug-ins too, and it's the model used in every other software project I've been involved with.

Maybe I'm just being old fashioned because "many files in one big repo" is the only model I've seen in action. From what you say, I guess I should look at Wordpress to see a project that uses "one repo per file" successfully?

I'm still not clear what the advantage would be of one repo per file. The disadvantages I see: many small repos are slower to check out, are more work to maintain, have a (slightly) bigger disk footprint, and you have to write a script to make sure you've pulled everything you need. Plus possibly Pat's concern about gitlab not allowing that many repos, but we don't know the answer to that yet.

But if this is just for the backend, and individual asset developers will have some way of submitting a single file and don't ever have to check out all those little repos, then I guess all that really matters is what makes the most sense to the registry development team. (And I hope I can be part of that team and help in some way, regardless of what decision you make about the number of repos.)

...Akkana

Hi,

I said I would not answer anymore, but I will (hopefully a last time) because I am weak and can't control my fingers! :P Anyway this discussion is very frustrating because my emails are not fully read. I'm sorry to say so Akkana, but your answer below is either off-topic, or actually going in my direction, and shows that you have not read my previous emails before saying you disagree. Now I know I write too long texts (and I'm sorry for this, I'm not good at this). But then don't read and ask me to get more concise rather than reading half and disagreeing on things I already answered (or said the opposite).

Or if you (not you specifically) don't want to read my opinion and have your own plans that will go on whatever I think, please don't ask. But don't ask the opinion, to not read it but contradict it after the first words. This is extremely annoying. I hope you can understand.

On Tue, Apr 5, 2016 at 4:17 AM, Akkana Peck wrote:

Jehan Pagès writes:
[on one repo per asset vs. one repo containing many assets]

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.

In the current GIMP source tree, circuit.scm,clothify.scm, coffee.scm, line-nova.scm, old-photo.scm, spinning-globe.scm and spyrogimp.scm (I just picked a random set) are all completely unrelated scripts. Yet there they all are, 53 different .scm files in the GIMP source repository in the plug-ins/script-fu/scripts/ directory, and similar unrelated collections in plug-ins/pygimp/plug-ins/ and plug-ins/ itself.

So that's the part which is either off-topic or actually going in my direction.

1/ Off-topic because these are the official released plugins. These are not user-made plugins delivered through a plugin interface. This is just completely different to what we are talking about! Of course we deliver GIMP with a minimum set of plugins (because without these, bare GIMP would be very limited. Well less now thanks to GEGL which replaced most filters into operations). So yes, that's a single release, together with GIMP, so this is one repository.

2/ Now let's say that we just absolutely want to consider the default plugins the same as user-contributed plugins, this is when it goes in my direction. They are delivered as a single-release? Then it is one single extension/asset, so yes that's a single repository. As simple as this. I said it previously: you can propose collection of plugins/scripts (you don't get one without the others.). Everybody is free. I said it before (so that's also a part where you did not read my previous emails).

But actually if we had a good plugin management system, where it is easy to install and update plugins, it may even be worth it to thin out our default provided plugins/scripts. There was this discussion the other day on the GIMP user mailing list when people noted that GIMP was slow to launch and that plugin startup were part of the cause. Elle was even saying that there are many plugins that she barely ever used so she cleaned out her GIMP installation from many of the default plugins.
The fact is that right now, as we all know, installing plugins is so old-fashioned (get some zip somewhere, uncompress it in some hidden directory, maybe play with file permissions…) that few people install any. The consequences is that if the default installation has to be released with a wide range of plugins, otherwise GIMP will look dumb. But with a plugin management system, we could push many of the rarely used plugins into the plugin directory, allowing people to easily install them on a whim, yet keeping a default GIMP quite light. And if we do this, this would not be a single release anymore. Probably every unrelated plugin could be on its own for people to choose which one they want.

You are arguing that it's easier/better to maintain unrelated assets each in its own repository. But evidently the GIMP development team agrees with me: they have and a bunch of unrelated script files together within one directory within one big repository. That's how I organize my GIMP plug-ins too, and it's the model used in every other software project I've been involved with.

Maybe I'm just being old fashioned because "many files in one big repo" is the only model I've seen in action. From what you say, I guess I should look at Wordpress to see a project that uses "one repo per file" successfully?

Wordpress uses one repo per plugin (well for plugins which want to be hosted by Wordpress. Once again this is not mandatory. Neither will it be for GIMP if we had a hosting system). A plugin can be a single file, yes, but it can also be dozens of files for very complex plugins.
And yes, Wordpress is successful. Last count, it was like more than 20% of the world websites. The most popular CMS of the world.

I'm still not clear what the advantage would be of one repo per file. The disadvantages I see: many small repos are slower to check out, are more work to maintain, have a (slightly) bigger disk footprint, and you have to write a script to make sure you've pulled everything you need. Plus possibly Pat's concern about gitlab not allowing that many repos, but we don't know the answer to that yet.

Aaaaargh! And this is the part where you have not read what I have said countless and countless of times in previous emails. So basically you have read none of my emails fully! You even dare say you have had no answer to somewhere I explicitly answered yesterday (and that's in the exact email you are answering to)! How crazy is that?

Let me quote myself from my previous email:

Since we would be using our own gitlab, how could we be hitting an account limit (we would set these ourselves)?

And from my email before that:

For me, this is better to just stick to tarball plugins if we cannot host our own controlled repository service.

And from another email before that:

The design I propose would not propose developers to host their code to github/github/any random git repository out there. We would have our own centralized system

And so on. I didn't even quote fully. Each of the quotes were partial to, and I explain in details my thoughts about the topic in the said emails. So you really cannot say I have not answered these! No, we won't check out repositories (I even gave the example of a service, OpenHub, which does checkout repositories for statistics, and that makes it slow to update. We don't want this!). And no we won't maintain third-party plugins! Mozilla does not maintain the thousands of user-contributed Firefox plugins. Automattic neither for all Wordpress plugins. We should make sure they are not malevolent or dangerous (and there can be various ways to ensure this) but that's it, not maintain them!
And we won't have any account limit problem (my previous email had the answer to this exact question!).

I have answered already to all of these points! Can you imagine how frustrating it is for me to read a contradiction to my proposition with parts showing you actually didn't read the full of it? Do you think I didn't read your email fully before answering? That would be pretty disrespectful.

Now I don't want to look like I am pissed or something. Well I am a little, because I felt like I lost some of my time these last days repeating myself and feeling like nobody read my emails even though I was asked personally to answer.

But anyway in the end, that's still technical discussions, and it made me think a little about the possibility of collections of plugins which can be separated into individual plugins. So some users who just want as much as possible and don't have time being choosy would just install the whole collection, whereas others could install them individually. So we could have a collection "Old Photograph" with a bunch of scripts related to processing old photographs. You could still install scripts individually, and if later you were to install the "Old Photograph" collection, any script from the collection already installed would not get installed a second time. I don't think that it would change the 1 plugin = 1 repo paradigm though. This would be more like tagging. For instance a single script could belong to several collections (which would not be possible if we decided a collection would be one repo with several plugins). Also a collection could contain plugins that you don't maintain for instance (this is also not possible if a collection were a repo).

And no, before anyone proposes, using submodules is not an acceptable solution since a plugins would be installed several times if you installed several collections including it. I don't want to overdesign the plugin metadata format with sub-plugins in subfolders or other crazy features before it even exists.

Anyway I'm still thinking of the idea of developer-side collections while having separate user-side plugins while keeping it simple conceptually. So I can still change my mind.

But just please, read my emails before answering, next time. ;-)

But if this is just for the backend, and individual asset developers will have some way of submitting a single file and don't ever have to check out all those little repos, then I guess all that really matters is what makes the most sense to the registry development team. (And I hope I can be part of that team and help in some way, regardless of what decision you make about the number of repos.)

I hope so! We need contributors for pretty much everything GIMP-related, even more skilled ones like you. Will you be at LGM? We would be able to speak of this, with Patrick and anyone interested, in better conditions than by email.

Jehan

...Akkana
_______________________________________________ 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

Hi, folks,

friom a packagers point of view I need recommendations about plugins that are worth to be packaged.

I need some help.

IMHO we should separate the wheat from the chaff finally.

Cheers.

Am 01.04.2016 um 22:32 schrieb Pat David:

Continuing on some discussions from irc...

Registry.gimp.org is down for the count.

I was thinking recently about some ideas for a possible replacement. Mostly thinking along the lines of what made the registry work well for folks.

In the rest of this email, I'll use the term "asset(s)" to refer to things like plug-ins, scripts, or brushes/gradients/curves/other assets.

Some essential functionality based on the old registry drupal instance:

1. Upload/Download assets for GIMP. 2. Describe the asset (usually by the uploader). 3. Comment on the assets.

This was handled previously by using drupal, which treated each entry as a post/node that included the ability to upload files, write about the files as a post, and had comment threads below it.

Keeping this functionality would be good, I think. The ability to post an asset is a given, but the ability to interact around it helps foster the community (and provides nice feedback for the authors).

From those thoughts, what would be nice to have in a replacement:

1. Provide at least the same previous functionality (as listed above). 2. Managed or easier to manage and keep updated. 3. Easier account management.
4. Collaborative environment for shared assets 5. Support possible GIMP integration in the future (one-click asset install?).

GitLab?
======

Initially, I had thought Github might be a good option for this but given its closed-source nature decided to investigate something like GitLab instead.

I like this idea personally due to some nice infrastructure:

1. The service is hosted + managed (and available as Free Software just in case we felt we needed to break out and host it ourselves). 2. The service integrates OAuth sign-in using a few different account types (lowers barrier to entry to participate). a. they use accounts, Google, Twitter, Github, or bitbucket accounts for sign-in.
3. Projects maintain all the git-goodness for control and tracking 4. Projects created as a git project can have a full description/README along with issue tracking integrated in the site

So, we can fulfill the original registry functionality and get the added benefit of a git infrastructure for those wanting to contribute, user accounts using OAuth to make it easy to participate, and the ability to do some interesting things (git submodules).

In speaking with Jehan about this, we should also consider what might be needed to support the ability to install assets from within GIMP in the future easily.

Organization
=========

Jehan suggested that each script/plugin/asset have it's own git repo. This would be handy, particularly if script authors did this as well (as it considerably eases the inclusion of external repos as submodules). However, akk points out that many folks don't (won't?) organize their repos in this way (it gets a little... unwieldy pretty quickly if you have many scripts).

I'd like some input on what would make the most sense or work best for possible organization of repos.

I was also thinking that we could include some simple metadata in both any script files and the README.md files as a means to possibly help parsing relevant information for automated inclusion at a later date (GIMP plug-ins installer type of idea).

Curation ======

Initially I was thinking that curating the scripts for inclusion would be important. It's certainly possible for a smaller subset of all of the available scripts from the registry now to pick out ones that we use and check that they're not malicious and properly tagged/included. For instance, there's a handful of scripts that I personally find myself using often and can help validate/curate for inclusion. I don't mind doing more as needed.

I just wanted to get a discussion started about how we might consider moving forward on something like this. I think the scripts/plug-ins are important enough to users that it would be good to try and get something up and running soon.

I have started experimenting with including submodules from other author repos and how it might look here:

https://gitlab.com/GIMP/GIMP-Scripts/tree/master

I look forward to hearing some thoughts on this!

pat

Lao-Tse sagt: Nichtstun ist besser, als mit viel Mhe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schtze, die ich hte und hege.
Der eine ist die Liebe, der zweite ist die Gengsamkeit, der dritte ist die Demut.
Nur der Liebende ist mutig, nur der Gengsame ist grozgig, nur der Demtige ist fhig zu herrschen.

Akkana Peck wrote:

I'm still not clear what the advantage would be of one repo per file.

Not to kick a week-old hornet's nest, but I'd like to point out that as a user looking for extensions/add-ons/scripts/etc, I find it much more convenient to download/clone a single script without being required to pull down a bunch of unrelated scripts as part of the same repository. This is even more the case if I happen to want to contribute code to that script.

Granted, perhaps there's a frontend that's developed which obfuscates or otherwise diminishes the need to get all of the undesired scripts. But despite the hassle (I have a few one-off scripts/add-ons for Blender on GitHub in their own repos), there are definitely some advantages for the people who aren't the primary developers.

-Jason

Hi,

For info, I wrote a "bit" of text after the meeting. It's somewhere in my hard drive, I'll have to look for it. I will publish things on the wiki so that we can discuss and collaborate on a spec.

Jehan

On Thu, May 5, 2016 at 12:07 AM, Pat David wrote:

Just a quick note for everyone (that either didn't attend LGM or didn't hear the results of the conversation I had with Joao and Jehan)...

After some back and forth we are currently considering managing our own infrastructure to host plugins/scripts.

We had a chance to speak (loudly in my case) at LGM and I will ping the list again when we have fleshed out some ideas a little further and start soliciting some feedback/ideas.

pat

On Tue, Apr 12, 2016 at 1:13 PM Jason van Gumster wrote:

Akkana Peck wrote:

I'm still not clear what the advantage would be of one repo per file.

Not to kick a week-old hornet's nest, but I'd like to point out that as a user
looking for extensions/add-ons/scripts/etc, I find it much more convenient to
download/clone a single script without being required to pull down a bunch of
unrelated scripts as part of the same repository. This is even more the case if
I happen to want to contribute code to that script.

Granted, perhaps there's a frontend that's developed which obfuscates or otherwise diminishes the need to get all of the undesired scripts. But despite
the hassle (I have a few one-off scripts/add-ons for Blender on GitHub in their
own repos), there are definitely some advantages for the people who aren't the
primary developers.

-Jason
_______________________________________________ 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

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