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. ~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-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
