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) 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. 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. 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 On 1 April 2016 at 17:32, Pat David <patdavid@xxxxxxxxx> 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@xxxxxxxxx > 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@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
