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

[Jehan Pagès <jehan marmottard gmail com>]

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 <akkana shallowsky com> 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