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

[Thorsten Stettin]

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 Mühe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die 
Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige 
ist fähig zu herrschen.


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

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

[Jehan Pagès]

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
___
gimp-developer-list mailing list
List address:

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

[Akkana Peck]

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
___
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] Gitlab as a replacement for registry.gimp.org

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