Hello, On Fri, Apr 1, 2016 at 10:52 PM, Joao S. O. Bueno <gwid...@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 <patda...@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-l...@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-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 http://film.zemarmot.net Patreon: https://patreon.com/zemarmot _______________________________________________ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
