On Fri, Apr 1, 2016 at 11:41 PM, Andrew Toskin <and...@tosk.in> wrote:
> I rather like GitLab, and this seems like at least as good a solution
> for a plugin registry as any other solution we've considered so far.
> In fact, I think GitLab (or some similar solution) would also be a major
> improvement for tracking the core GIMP software. As an occasional
> contributor just to the documentation, I find Bugzilla, and the process
> of creating and uploading patch files, cumbersome and weirdly
> old-fashioned. GitLab could do everything Bugzilla or cgit can, and much
> more, _and_ it's got a much better UI and workflow.

The discussion is not about core GIMP and I don't think there are any
advantages in migrating GIMP out of GNOME infrastructure. I mean, if
there were several long-term contributors willing to maintain our own
infrastructure, and which we can trust to not disappear in a few
months, why not. And even so, I'm not sure what would be the gain
there. Bugzilla works very well, in my opinion. The patch process is
like 100x better than the weird fork logics that github imposes. And I
don't see anything in the web UI that I can't do 1000x better in my

Anyway this thread is about plugins and since there is nearly no
chance for GIMP migrating to a gitlab hosting, let's not diverge the


> ~Andrew
> On 2016-04-01 13:32, Pat David 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 [1]
>> I look forward to hearing some thoughts on this!
>> pat
> Links:
> ------
> [1] https://gitlab.com/GIMP/GIMP-Scripts/tree/master
> _______________________________________________
> gimp-developer-list mailing list
> List address:    gimp-developer-l...@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
Patreon: https://patreon.com/zemarmot
gimp-web-list mailing list

Reply via email to