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

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

Hi,

On Mon, Apr 4, 2016 at 2:50 AM, Akkana Peck <akkana shallowsky com> 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