Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hi, folks, friom a packagers point of view I need recommendations about plugins that are worth to be packaged. I need some help. IMHO we should separate the wheat from the chaff finally. Cheers. Am 01.04.2016 um 22:32 schrieb Pat David: 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 -- Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige ist fähig zu herrschen. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gi
Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hi, On Mon, Apr 4, 2016 at 3:00 AM, Akkana Peck wrote: > Just agreeing with a few of Ofnuts' points: > > Ofnuts writes: >> Author: >> - communications with users: forum, etc. Mail notification necessary > > +1. With the current setup, I remember going to a page I'd made for > one of my plug-ins and discovering there was a question there from > four years earlier that I'd had no idea about. > >> - ability to share/transmit ownership > > Good one! > >> - I don't think this system should be a place to maintain/share the source >> code. We could however enforce a FOSS/CC discipline and require the source >> files to be provided (for some assets, this could mean the original XCF/SVG >> file...) > > I like the experiments Pat has been doing with making links inside a > repo that link to other repos. If the GIMP plugin repository can > include files from a developer's site on github or wherever, This experiment was about a perfectly hand-curated small set of plugins. I completely understand that this is also very interesting. But Pat does not need me to do this. If that is what people have in mind, I won't be onboard. Don't get me wrong. This is still very cool, I support the project and I could help from time to time. But this is not as high a priority for me as other things. And that's a completely different project to the one I am talking about. I am talking about a plugin management system, with a user side (within GIMP, to be able to browse hundreds of plugins, install/uninstall them, automatic update when there are new versions…) and a developer side (a way to upload their plugins, which can be as basic as uploading a zip of their code, up to fancy GIMP-hosted repositories). The curation is not contradictory to my idea and could be used within the bigger plugin management system (there could be a small set of GIMP team-maintained plugins, or team picks, and "approved" plugins, etc.), but this curation cannot be the technical base of the whole system. Because no, using a central git repository with submodules to user-maintained repositories inside it is not scaling up! I don't see at all actually how submodules could be the base of anything for a plugin management system. > that solves the problem of developers who are actively improving > a plugin but forget that they also need to update the version on > GIMP's repository. No, setting a submodule for a given third-party repository does not magically give you write access to this repository (and fortunately! uhuh). You'd still have to fork if you want to improve the code of a given repository when the original author is not responding. Once again, this is manual curation. >> User: >> - straightforward, no-questions-asked downloads >> - easy registration for forums >> - semi-anonymous use of forums (guest mode without registration, but with >> some more hurdles such as captchas) Why would we have forums? We are talking about a plugin system. We could have comments on plugins, why not. And *if: we decided to have a source hosting (gitlab or other), then obviously bug reports. But that's it. Now if people want generic official forums (I know I don't, we already have mailing lists, enough for me), that's a completely different discussion. >> - search capabilities > > - browse capabilities, by category or keyword: browsing all the > plugins in the color category isn't the same as searching for > everything that has the word "color" anywhere in the description, > a major problem with the previous plug-in repository. And maybe > also by date: browse the recently added plugins. I agree with most features above. But just to make things clear: we can't have all this for a first release. But yes this kind of things have to be prepared from the extension format (with keywords, and categories/tags for instance). Also let's not compare with the old registry. This was just a glorified do-it-all website where anyone could just upload anything, with basically no failsafe whatsoever. This had never been thought as a plugin system, but was only a generic hosting system (Drupal if not mistaken). In my opinion, there is basically *nothing* to be used from the old system. If you want to compare, please let's compare with good existing plugin directories out there (Firefox, Wordpress, whatever has a huge base of plugins) and try to see what works and what does not work well for them. Let's work with good examples. Jehan > ...Akkana > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@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-developer-list mailing list List address:gimp-developer-list@gnome.org List membership:
Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Just agreeing with a few of Ofnuts' points: Ofnuts writes: > Author: > - communications with users: forum, etc. Mail notification necessary +1. With the current setup, I remember going to a page I'd made for one of my plug-ins and discovering there was a question there from four years earlier that I'd had no idea about. > - ability to share/transmit ownership Good one! > - I don't think this system should be a place to maintain/share the source > code. We could however enforce a FOSS/CC discipline and require the source > files to be provided (for some assets, this could mean the original XCF/SVG > file...) I like the experiments Pat has been doing with making links inside a repo that link to other repos. If the GIMP plugin repository can include files from a developer's site on github or wherever, that solves the problem of developers who are actively improving a plugin but forget that they also need to update the version on GIMP's repository. > User: > - straightforward, no-questions-asked downloads > - easy registration for forums > - semi-anonymous use of forums (guest mode without registration, but with > some more hurdles such as captchas) > - search capabilities - browse capabilities, by category or keyword: browsing all the plugins in the color category isn't the same as searching for everything that has the word "color" anywhere in the description, a major problem with the previous plug-in repository. And maybe also by date: browse the recently added plugins. ...Akkana ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Off the top of my head, three points of view on such a thing: Admin; - good spam prevention (IP banning, lock on keywords, approval of first post...) - malware prevention. This could be a trust system (but don't forget that even trustable persons could have their account hijacked). Reviewing SCM/PY is easy. Reviewing C is more complex, because we have to check that the binary is indeed matching the source we review, or we have to rebuild it (for all platforms...). - easy user management Author: - decent registration procedure - ease of publication (that goes a bit against security/spam, so a balance should be found) - statistics (I'm a sucker for download stats, especially when they show me that my more popular scripts aren't the ones I think; so far nothing beats SourceForge...) - ability to document things easily: formatting with markdown or BBCode, including support for images. Ability to upload text and images from my PC (v.s. editing in a web page) is a plus - communications with users: forum, etc. Mail notification necessary - ability to share/transmit ownership - I don't think this system should be a place to maintain/share the source code. We could however enforce a FOSS/CC discipline and require the source files to be provided (for some assets, this could mean the original XCF/SVG file...) - Human-readable, permanent URL to homepage so that it can be posted on other sites User: - straightforward, no-questions-asked downloads - easy registration for forums - semi-anonymous use of forums (guest mode without registration, but with some more hurdles such as captchas) - search capabilities ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hello, On Fri, Apr 1, 2016 at 10:52 PM, Joao S. O. Bueno 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 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.
Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org
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 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 inclusi
[Gimp-developer] Gitlab as a replacement for registry.gimp.org
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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
