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

[Jehan Pagès]

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

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

[Pat David]

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

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

[Jason van Gumster]

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

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

[Jehan Pagès]

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. 

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

[Akkana Peck]

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.

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

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

[Jehan Pagès]

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 

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

[Pat David]

I am sorry for perhaps causing any confusion or misunderstandings :(.  I
suck at conveying information.

Let me try a slightly different approach that coincides with my thought
process...

We are really approaching two things that are related in this discussion.

1. Registry Replacement
2. GIMP Asset Installer


Registry Replacement

My initial thoughts were to build out a replacement for the functionality
that was available in regsitry.gimp.org (rgo).

I listed in my initial email what I thought was the essential functionality:

1. Host assets for GIMP.
2. Asset description page to inform users what it is, etc.
3. Commenting/feedback/support on the asset (social interaction).

If I'm not mistaken, right now all of this functionality is already
available in a service like GitLab.  I can walk through the rgo archives
and start uploading the latest versions of assets that are licensed to
allow me to do so and all of the points above will be covered through the
existing infrastructure of GitLab.

If we simply wanted to mirror the functionality of rgo as it existed before
we had to freeze it, we can do just that (walking through the archives and
uploading the assets into the GitLab instance).  This would make the
scripts available to users again and in some cases we can replicate the
description posts from rgo as well.

This technically _could_ be the end of the discussion.  But...

I know that Jehan has been thinking for some time about integrating some
sort of asset installer from within GIMP.
I love this idea and want to make sure that we organize content on any
"Registry 2.0" idea in a way that supports this capability as well as
possible.



GIMP Asset Installer
===
There are some organizational ideas that we need to work through to best
support this idea, I think.

Initially, I had mentioned that I was going to refer to
plug-ins/scripts/brushes/etc... as simply "assets" to be generic.  An asset
can be a single .scm file, multiple .scm files, files to compile a plugin,
brushes, gradients, files to compile a gegl op, etc...

[image: assets.png]
[assets.png]
https://gitlab.com/GIMP/GIMP-Scripts/raw/aced57ae1fda9b38ed300e074c6a6e3327395529/ideas/assets.png



GIT REPO

There are two main thoughts concerning organization on a git infrastructure
to support this.

1. A single organization/account that will contain a single git repo for
_each_ asset.
2. A single repo that contains assets + references to external assets as
well.



Single Repo
-
My personal ideas are to use a single repo that would include all of the
assets inside of it, as well as submodules of external repositories from
their respective authors.  Basically, #2 from above.  (I should note that I
personally _love_ the idea of one repository = one asset, but I am also
pragmatic and realize that this may get unwieldy very quickly.  I do still
wish it could be that way, though... ).

[image: repo-full.png]
[repo-full.png]
https://gitlab.com/GIMP/GIMP-Scripts/raw/master/ideas/repo-full.png

The repository can contain assets inside of it as well as submodules.  The
submodules themselves can either be a singular repository with assets, or
repository with multiple assets contained inside.  Importantly, the
submodule can be a completely different git repository owned by someone
else (and is basically it's own git repo with logs, etc...).

So, in this approach, the "Registry 2.0" repo by itself can contain:

1. Assets
2. Submodules
a. Single repository of an asset
b. Single repository of multiple assets (not necessarily owned by us)

(I also just realized that this idea could be considered a _super_set of
what Jehan wants in single repo = single asset).

The important thing for supporting an installer in the future is a way to
enumerate the list of available assets contained inside the repo.  I was
personally thinking some sort of "Asset Index" file to point to all of the
relevant assets for automation. [1]

What's nice about this approach is that we can house assets ourselves in
the main repo, house assets in other repos ourselves, or we can link in
other authors assets as submodules.



Single Account
--
The approach as I understand it from Jehan for a single repository = single
asset would look something like this:

[image: account-full.png]
[account-full.png]
https://gitlab.com/GIMP/GIMP-Scripts/raw/master/ideas/account-full.png

In this case, the account would contain multiple git repos, with 1:1
mapping between asset:repository.

One of the problems I can see with this approach is:

1. A full git repo for a single .scm file seems like overkill?
2. Asset authors would _have_ to use our git repo (or would have to sync to
them when they wanted to push something new).
3. Will we hit a limit to the number of repos allowed per account? (Not
sure - can't find hard numbers on this at gitlab).



[1] Asset Index
--
Regardless of which approach is used, the 

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

[Pat David]

I'm writing up a response (with pictures and everything!) in a hope to
clarify some of the things... :)

On Mon, Apr 4, 2016 at 9:50 AM Kevin Payne <payn...@hotmail.com> wrote:

> At the risk of putting words into Pat's mouth, wasn't he referring to them
> as assets?
>
> Kevin
>
>
> 
> From: gimp-developer-list <gimp-developer-list-boun...@gnome.org> on
> behalf of Jehan Pagès <jehan.marmott...@gmail.com>
> 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 <schum...@gmx.de>
> wrote:
> >> Gesendet: Montag, 04. April 2016 um 15:48 Uhr
> >> Von: "Jehan Pagès" <jehan.marmott...@gmail.com>
> >
> >> On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher <schum...@gmx.de>
> 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
> ___
> 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
>
-- 
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

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

[Kevin Payne]

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

Kevin 



From: gimp-developer-list <gimp-developer-list-boun...@gnome.org> on behalf of 
Jehan Pagès <jehan.marmott...@gmail.com>
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 <schum...@gmx.de> wrote:
>> Gesendet: Montag, 04. April 2016 um 15:48 Uhr
>> Von: "Jehan Pagès" <jehan.marmott...@gmail.com>
>
>> On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher <schum...@gmx.de> 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
___
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

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

[Jehan Pagès]

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

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

[Michael Schumacher]

> 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

___
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

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

[Jehan Pagès]

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

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

[Michael Schumacher]

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

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

[Jehan Pagès]

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 

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

[Akkana Peck]

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