GNOME.org
 

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

Hello,

On Fri, Apr 1, 2016 at 10:52 PM, Joao S. O. Bueno <gwidion gmail com> 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 <patdavid gmail com> 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]