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.
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
> 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
> Initially, I had thought Github might be a good option for this but given
> its closed-source nature decided to investigate something like GitLab
> 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.
> 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
> 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).
> 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!
gimp-web-list mailing list