Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hi, For info, I wrote a "bit" of text after the meeting. It's somewhere in my hard drive, I'll have to look for it. I will publish things on the wiki so that we can discuss and collaborate on a spec. Jehan On Thu, May 5, 2016 at 12:07 AM, Pat David wrote: > Just a quick note for everyone (that either didn't attend LGM or didn't > hear the results of the conversation I had with Joao and Jehan)... > > After some back and forth we are currently considering managing our own > infrastructure to host plugins/scripts. > > We had a chance to speak (loudly in my case) at LGM and I will ping the > list again when we have fleshed out some ideas a little further and start > soliciting some feedback/ideas. > > pat > > > On Tue, Apr 12, 2016 at 1:13 PM Jason van Gumster > wrote: > >> >> Akkana Peck wrote: >> >> > I'm still not clear what the advantage would be of one repo per >> > file. >> >> Not to kick a week-old hornet's nest, but I'd like to point out that as a >> user >> looking for extensions/add-ons/scripts/etc, I find it much more convenient >> to >> download/clone a single script without being required to pull down a bunch >> of >> unrelated scripts as part of the same repository. This is even more the >> case if >> I happen to want to contribute code to that script. >> >> Granted, perhaps there's a frontend that's developed which obfuscates or >> otherwise diminishes the need to get all of the undesired scripts. But >> despite >> the hassle (I have a few one-off scripts/add-ons for Blender on GitHub in >> their >> own repos), there are definitely some advantages for the people who aren't >> the >> primary developers. >> >> -Jason >> ___ >> 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 >> > -- > 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 -- 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
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Just a quick note for everyone (that either didn't attend LGM or didn't hear the results of the conversation I had with Joao and Jehan)... After some back and forth we are currently considering managing our own infrastructure to host plugins/scripts. We had a chance to speak (loudly in my case) at LGM and I will ping the list again when we have fleshed out some ideas a little further and start soliciting some feedback/ideas. pat On Tue, Apr 12, 2016 at 1:13 PM Jason van Gumster wrote: > > Akkana Peck wrote: > > > I'm still not clear what the advantage would be of one repo per > > file. > > Not to kick a week-old hornet's nest, but I'd like to point out that as a > user > looking for extensions/add-ons/scripts/etc, I find it much more convenient > to > download/clone a single script without being required to pull down a bunch > of > unrelated scripts as part of the same repository. This is even more the > case if > I happen to want to contribute code to that script. > > Granted, perhaps there's a frontend that's developed which obfuscates or > otherwise diminishes the need to get all of the undesired scripts. But > despite > the hassle (I have a few one-off scripts/add-ons for Blender on GitHub in > their > own repos), there are definitely some advantages for the people who aren't > the > primary developers. > > -Jason > ___ > 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 > -- Pat David https://pixls.us http://blog.patdavid.net ___ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hi, Just giving a few answers. I really can't make the time right now and I think we will have to discuss this with voice, because it looks like several things I say are really not understandable (well they are by me, but my English may be lacking! At least I have to say the same thing again). On Mon, Apr 4, 2016 at 7:00 PM, Pat David wrote: > GIT REPO > > There are two main thoughts concerning organization on a git infrastructure > to support this. > > 1. A single organization/account that will contain a single git repo for > _each_ asset. > 2. A single repo that contains assets + references to external assets as > well. > > > > Single Repo > - > My personal ideas are to use a single repo that would include all of the > assets inside of it, as well as submodules of external repositories from > their respective authors. Basically, #2 from above. (I should note that I > personally _love_ the idea of one repository = one asset, but I am also > pragmatic and realize that this may get unwieldy very quickly. I do still > wish it could be that way, though... ). Really I don't understand this point which Akkana is raising. Has anyone ever made plugins for various software? I have, for a bunch, many dead now, some still living. And never have I ever thought "oh let's put all my completely unrelated plugins into the same repository"! This is like the base of code organization, you just have separate items. I have a bunch of repositories of my own, and have a few dozens of repositories from various projects which I have needed at some point. I organized the repositories, some on my personal computer (the ones which I code with the most often, or which I am working with lately), some on a server (the ones which I don't code with often, or not lately). And really, I have absolutely no problem with such an organization. 0, NULL, nada! Why is it hard to consider that 2 different software are better in different repositories rather than in the same. You can still have subdirectories locally on your computer to organize. But don't bring your personal organization into the source code! And yeah maybe some plugins are just a single file. So what? That does not make it any more useless. If it is a good plugin, it is a good plugin by himself. No need to absolutely want to fill in. Now that is just my personal opinion on the matter, and I did not want to bring it in anyway but in the end, after reading this a few times here or on IRC, I could not stop myself. Why didn't I not want to give my opinion? Because it does not matter! I said it 10 times. If you want to have all your plugins in a single repository, no matter how different they are, you can still do it on your github, gitlab or whatever-else account. Just upload individual archives in the end. Or even just make it a collection of scripts and tell users that this is a all-or-nothing plugin. But someone's organization should not change the fact that for the service, 1 asset is 1 asset. This is a single item which will be downloaded as a single asset by the user, be it composed of 1 or a 1000 files. I am not going to ask Wordpress if I could not have all my Wordpress plugins into a single repository because it is easier for me and that I don't like the concept of 1 repository per plugin. Now I will contradict myself: I actually have 2 such repositories, one for various bash scripts which I don't feel like making into their own repositories indeed, and the other one with a few (less than Akkana even) GIMP scripts. So yes, I actually even contradicted myself on this very topic of GIMP scripts! But the point is that these shell scripts or GIMP plugins are only for my personal use right now. I actually call them with stupid names like "jehan-scripts" or something. But that's because I have not been making them available to the world and I don't have access to a GIMP service whose main goal was to manage GIMP plugins! If there were such a server, dedicated to GIMP scripts, I would just separate the repository into what make sense as individual plugins. Because that's for public consumption, not just for me, and because nobody will install "Jehan's scripts" with several unrelated scripts, but they may install a plugin with a clear title and providing a given useful feature. So I completely see where you come from Akkana. And I agree. If you are hosting on github, I'd likely do the same as you, and would make some scripts to generate various tarballs for release. But here we are speaking of a GIMP-dedicated hosting server which provides you with as many repositories as you want (provided they are GIMP plugins, of course!). Doesn't that make sense to just have a clear conceptual separation? > [image: repo-full.png] > [repo-full.png] > https://gitlab.com/GIMP/GIMP-Scripts/raw/master/ideas/repo-full.png > > The repository can contain assets inside of it as well as submodules. The > submodules themselves can either be a singular repository w
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hi, I said I would not answer anymore, but I will (hopefully a last time) because I am weak and can't control my fingers! :P Anyway this discussion is very frustrating because my emails are not fully read. I'm sorry to say so Akkana, but your answer below is either off-topic, or actually going in my direction, and shows that you have not read my previous emails before saying you disagree. Now I know I write too long texts (and I'm sorry for this, I'm not good at this). But then don't read and ask me to get more concise rather than reading half and disagreeing on things I already answered (or said the opposite). Or if you (not you specifically) don't want to read my opinion and have your own plans that will go on whatever I think, please don't ask. But don't ask the opinion, to not read it but contradict it after the first words. This is extremely annoying. I hope you can understand. On Tue, Apr 5, 2016 at 4:17 AM, Akkana Peck wrote: > Jehan Pagès writes: > [on one repo per asset vs. one repo containing many assets] >> Really I don't understand this point which Akkana is raising. Has >> anyone ever made plugins for various software? I have, for a bunch, >> many dead now, some still living. And never have I ever thought "oh >> let's put all my completely unrelated plugins into the same >> repository"! This is like the base of code organization, you just have >> separate items. I have a bunch of repositories of my own, and have a >> few dozens of repositories from various projects which I have needed >> at some point. > > In the current GIMP source tree, circuit.scm,clothify.scm, > coffee.scm, line-nova.scm, old-photo.scm, spinning-globe.scm and > spyrogimp.scm (I just picked a random set) are all completely > unrelated scripts. Yet there they all are, 53 different .scm files > in the GIMP source repository in the plug-ins/script-fu/scripts/ > directory, and similar unrelated collections in > plug-ins/pygimp/plug-ins/ and plug-ins/ itself. So that's the part which is either off-topic or actually going in my direction. 1/ Off-topic because these are the official released plugins. These are not user-made plugins delivered through a plugin interface. This is just completely different to what we are talking about! Of course we deliver GIMP with a minimum set of plugins (because without these, bare GIMP would be very limited. Well less now thanks to GEGL which replaced most filters into operations). So yes, that's a single release, together with GIMP, so this is one repository. 2/ Now let's say that we just absolutely want to consider the default plugins the same as user-contributed plugins, this is when it goes in my direction. They are delivered as a single-release? Then it is one single extension/asset, so yes that's a single repository. As simple as this. I said it previously: you can propose collection of plugins/scripts (you don't get one without the others.). Everybody is free. I said it before (so that's also a part where you did not read my previous emails). But actually if we had a good plugin management system, where it is easy to install and update plugins, it may even be worth it to thin out our default provided plugins/scripts. There was this discussion the other day on the GIMP user mailing list when people noted that GIMP was slow to launch and that plugin startup were part of the cause. Elle was even saying that there are many plugins that she barely ever used so she cleaned out her GIMP installation from many of the default plugins. The fact is that right now, as we all know, installing plugins is so old-fashioned (get some zip somewhere, uncompress it in some hidden directory, maybe play with file permissions…) that few people install any. The consequences is that if the default installation has to be released with a wide range of plugins, otherwise GIMP will look dumb. But with a plugin management system, we could push many of the rarely used plugins into the plugin directory, allowing people to easily install them on a whim, yet keeping a default GIMP quite light. And if we do this, this would not be a single release anymore. Probably every unrelated plugin could be on its own for people to choose which one they want. > You are arguing that it's easier/better to maintain unrelated assets > each in its own repository. But evidently the GIMP development team > agrees with me: they have and a bunch of unrelated script files > together within one directory within one big repository. That's how > I organize my GIMP plug-ins too, and it's the model used in every > other software project I've been involved with. > > Maybe I'm just being old fashioned because "many files in one big > repo" is the only model I've seen in action. From what you say, I > guess I should look at Wordpress to see a project that uses "one > repo per file" successfully? Wordpress uses one repo per plugin (well for plugins which want to be hosted by Wordpress. Once again this is not mandatory. Neither will it be for G
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Jehan Pagès writes: [on one repo per asset vs. one repo containing many assets] > Really I don't understand this point which Akkana is raising. Has > anyone ever made plugins for various software? I have, for a bunch, > many dead now, some still living. And never have I ever thought "oh > let's put all my completely unrelated plugins into the same > repository"! This is like the base of code organization, you just have > separate items. I have a bunch of repositories of my own, and have a > few dozens of repositories from various projects which I have needed > at some point. In the current GIMP source tree, circuit.scm,clothify.scm, coffee.scm, line-nova.scm, old-photo.scm, spinning-globe.scm and spyrogimp.scm (I just picked a random set) are all completely unrelated scripts. Yet there they all are, 53 different .scm files in the GIMP source repository in the plug-ins/script-fu/scripts/ directory, and similar unrelated collections in plug-ins/pygimp/plug-ins/ and plug-ins/ itself. You are arguing that it's easier/better to maintain unrelated assets each in its own repository. But evidently the GIMP development team agrees with me: they have and a bunch of unrelated script files together within one directory within one big repository. That's how I organize my GIMP plug-ins too, and it's the model used in every other software project I've been involved with. Maybe I'm just being old fashioned because "many files in one big repo" is the only model I've seen in action. From what you say, I guess I should look at Wordpress to see a project that uses "one repo per file" successfully? I'm still not clear what the advantage would be of one repo per file. The disadvantages I see: many small repos are slower to check out, are more work to maintain, have a (slightly) bigger disk footprint, and you have to write a script to make sure you've pulled everything you need. Plus possibly Pat's concern about gitlab not allowing that many repos, but we don't know the answer to that yet. But if this is just for the backend, and individual asset developers will have some way of submitting a single file and don't ever have to check out all those little repos, then I guess all that really matters is what makes the most sense to the registry development team. (And I hope I can be part of that team and help in some way, regardless of what decision you make about the number of repos.) ...Akkana ___ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
At the risk of putting words into Pat's mouth, wasn't he referring to them as assets? Kevin From: gimp-developer-list on behalf of Jehan Pagès Sent: 04 April 2016 15:19 To: Michael Schumacher Cc: gimp-web-list; GIMP Developer List Subject: Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org On Mon, Apr 4, 2016 at 4:04 PM, Michael Schumacher wrote: >> Gesendet: Montag, 04. April 2016 um 15:48 Uhr >> Von: "Jehan Pagès" > >> On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher wrote: > >> > I am also still puzzled how the "one repository per 'script/plugin'" (we >> > really need a better term for that concept) approach will be managed. >> >> Let's call them "extensions" for the time being (since we already use >> the term "plugin" and "scripts", but I don't think we use the term >> "extension" yet). > > We do, and it has a very specific meaning - for example, Script-Fu is a > GIMP_EXTENSION. Right. I forgot about this. Jehan > -- > Regards, > Michael > GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD > > ___ > 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-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-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hi, On Mon, Apr 4, 2016 at 2:50 AM, Akkana Peck wrote: > Andrew Toskin writes: >> > On 2016-04-01 13:32, Pat David wrote: >> > 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). >> >> Whether or not we can get plugin developers to follow it, separating >> scripts and plugins into different repositories seems like a good >> recommendation, for a number of reasons. For plugin and script authors, >> it would make managing bugs and user feedback easier. > > It would make managing repositories much harder, though. > > I currently have roughly 20 GIMP scripts and plug-ins in my > gimp-plugins repository, and would want to share maybe 15 of them > (some are silly and not worth sharing). Please don't force me to > create 20 different repositories, most containing only a single > python script. It clutters my github (or, I assume, gitlab) profile, When I read this, I understand that I am really not clear. The design I propose would not propose developers to host their code to github/github/any random git repository out there. We would have our own centralized system, say called extensions.gimp.org (or reusing registry.gimp.org, why not). This could be a gitlab instance (since patdavid proposed so. Looks like a goot idea), customized to our needs. And this would be made to host GIMP plugin/contents only (we could have git hooks checking contents on a `git push` and allowing only certain files so that it won't be possible to just push any random file). So no, I am not saying and have never said that we would grab repository from "elsewhere". I know patdavid seemed to have such an idea at some point, but I thought we made the point clear on IRC. Having the possibility to register any repository out there, it immediately makes me think of OpenHub (openhub.net). For anyone using OpenHub, it is cool, but you probably also noticed that it is slow as hell (often to the point it is basically "down" from user viewpoint), and that repository information are usually late by days if not weeks. Of course one could assume they just don't have enough servers to handle the load, but what makes think that the GIMP project would be able to do what several companies have tried (OpenHub has been bought a few times. It used to be called Ohloh) and basically failed? A system as you propose means basically having to pull random repositories all the time to know what's new (most of them would probably never have anything new), and looping forever. So no, that's not and has never been what I am proposing. This design is a failure by nature. Being a centralized system means: - less load. We don't need to check for hundreds of user repository. We are just waiting for them to push. - reactive: a developer tags its master? Bam! New plugin release. It's available in GIMP installations out there. We can easily have git hooks checking for tags. A OpenHub-style system, you would wait days or weeks before you even see your plugin in GIMP. - more control over the contents and refusing whatever should not be part of a GIMP extension (again with git hooks), like random binaries. You can't control and forbid contents from a remote repository. Conclusion: you won't have your github profile cluttered with dozens of new repository. You will have your extensions.gimp.org profile filled with as many repositories as you have extensions there. And that makes sense to me. If you were look at my Wordpress user page (they don't seem to have these in a public fashion, but whatever) or my pypi page (same), or whatever else, you will not see a single big project called "All of Jehan's code", no you would see a list of smaller projects with meaningful individual names. > assuming they'd even let me create that many repos; it makes it hard So nobody asks you to make repos on github. But if you really insisted and did not want to host your code on extensions.gimp.org, then you could your single big repo on github or anywhere else, and just generate archives that you could upload for every release on extensions.gimp.org. Handling per-release tarball is a basic feature. Wordpress for instance also provide code repository, but developers are not forced to use them and can just release tarball at regular intervals. Then you can do whatever you want to manage multiple extensions into a single repository. > to keep multiple machines current since I have to cd into each of > those repos and make sure they're in sync; and it's harder to set > up (I have to do things like edit .git/config by hand in 20 repos > instead of just one to do things like make pushurl !- url). Side note: saying you have to do this kind of stuff is exa
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
On Mon, Apr 4, 2016 at 4:04 PM, Michael Schumacher wrote: >> Gesendet: Montag, 04. April 2016 um 15:48 Uhr >> Von: "Jehan Pagès" > >> On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher wrote: > >> > I am also still puzzled how the "one repository per 'script/plugin'" (we >> > really need a better term for that concept) approach will be managed. >> >> Let's call them "extensions" for the time being (since we already use >> the term "plugin" and "scripts", but I don't think we use the term >> "extension" yet). > > We do, and it has a very specific meaning - for example, Script-Fu is a > GIMP_EXTENSION. Right. I forgot about this. Jehan > -- > Regards, > Michael > GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD > > ___ > 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
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hi, On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher wrote: >> Gesendet: Montag, 04. April 2016 um 12:03 Uhr >> Von: "Jehan Pagès" > >> When I read this, I understand that I am really not clear. > >> So no, I am not saying and have never said that we would grab >> repository from "elsewhere". I know patdavid seemed to have such an >> idea at some point, but I thought we made the point clear on IRC. > > It looks like you went out of that IRC meeting with an different impression > than I. > > > What I remember from the meeting: > > - a repository or repositories *on gitlab.com* to host all of the official, > curated resources > - encouraging other developers to use Git (on github, gitlab, savannah, ...) > as well, and possibly add their repositories as submodules/subtrees > (with technical details to be filled in by people who know about git than > me) > - use gitlab.com as opposed to github to be able to (if the need arises, for > example gitlab turning evil) host an instance ourselves and migrate > everything there In any cases, we should not go the road of syncing with repositories of third-party services (neither github nor gitlab, nor whatever). I think this is just a road to hell. With time passing and hundreds and hundreds of plugins. And there would be no control over their contents, and so on. For me, this is better to just stick to tarball plugins if we cannot host our own controlled repository service. > I am also still puzzled how the "one repository per 'script/plugin'" (we > really need a better term for that concept) approach will be managed. Let's call them "extensions" for the time being (since we already use the term "plugin" and "scripts", but I don't think we use the term "extension" yet). Anyway the point is to have a single page for a single extension. If you want to go to the page for a Firefox extension, you don't get a page of all the extensions made by this particular developer (or team). You get the description for this one extension. This is the same. One single extension gets one page (and one single repository, and one single bug tracker, and so on). It does not share with other extensions (same developer or not). This is the whole conceptual point: each extension is separate. Now I repeat: an extension can be a whole collection of scripts or plugins. If all your scripts make sense together, and you want users to install them all at once, that's possible. You still have one single extension (with a single page, a single repo…), simply it has 10 or maybe why not 100 scripts inside (which themselves may register several procedures each, as you noted earlier). So that's simple: - if you conceptually associate your scripts/plugins/resources like being part of the same thing, then you have them all in a single repository and they are distributed as a single extension. - else if you conceptually consider these scripts/plugins/resources like being different unrelated items (they just happen to all be made by the same developer. Other than this, there is no reason to install them together), they are different extensions. As a consequence, they are in different repositories. Jehan > Maybe this is a good time to remind everyone that Wilber, our IRC bot, has > the Meetbot plugin installed: > http://meetbot.debian.net/Manual.html > > Using it more frequently would make even small, rather informal meetings with > all of their action items, agreements and disagreements easier to record. > > > -- > Regards, > Michael > GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD > ___ > 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
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
I'm writing up a response (with pictures and everything!) in a hope to clarify some of the things... :) On Mon, Apr 4, 2016 at 9:50 AM Kevin Payne wrote: > At the risk of putting words into Pat's mouth, wasn't he referring to them > as assets? > > Kevin > > > > From: gimp-developer-list on > behalf of Jehan Pagès > Sent: 04 April 2016 15:19 > To: Michael Schumacher > Cc: gimp-web-list; GIMP Developer List > Subject: Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for > registry.gimp.org > > On Mon, Apr 4, 2016 at 4:04 PM, Michael Schumacher > wrote: > >> Gesendet: Montag, 04. April 2016 um 15:48 Uhr > >> Von: "Jehan Pagès" > > > >> On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher > wrote: > > > >> > I am also still puzzled how the "one repository per 'script/plugin'" > (we really need a better term for that concept) approach will be managed. > >> > >> Let's call them "extensions" for the time being (since we already use > >> the term "plugin" and "scripts", but I don't think we use the term > >> "extension" yet). > > > > We do, and it has a very specific meaning - for example, Script-Fu is a > GIMP_EXTENSION. > > Right. I forgot about this. > > Jehan > > > -- > > Regards, > > Michael > > GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD > > > > ___ > > 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-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 > -- Pat David https://pixls.us http://blog.patdavid.net ___ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
> Gesendet: Montag, 04. April 2016 um 15:48 Uhr > Von: "Jehan Pagès" > On Mon, Apr 4, 2016 at 3:06 PM, Michael Schumacher wrote: > > I am also still puzzled how the "one repository per 'script/plugin'" (we > > really need a better term for that concept) approach will be managed. > > Let's call them "extensions" for the time being (since we already use > the term "plugin" and "scripts", but I don't think we use the term > "extension" yet). We do, and it has a very specific meaning - for example, Script-Fu is a GIMP_EXTENSION. -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
> Gesendet: Montag, 04. April 2016 um 12:03 Uhr > Von: "Jehan Pagès" > When I read this, I understand that I am really not clear. > So no, I am not saying and have never said that we would grab > repository from "elsewhere". I know patdavid seemed to have such an > idea at some point, but I thought we made the point clear on IRC. It looks like you went out of that IRC meeting with an different impression than I. What I remember from the meeting: - a repository or repositories *on gitlab.com* to host all of the official, curated resources - encouraging other developers to use Git (on github, gitlab, savannah, ...) as well, and possibly add their repositories as submodules/subtrees (with technical details to be filled in by people who know about git than me) - use gitlab.com as opposed to github to be able to (if the need arises, for example gitlab turning evil) host an instance ourselves and migrate everything there I am also still puzzled how the "one repository per 'script/plugin'" (we really need a better term for that concept) approach will be managed. Maybe this is a good time to remind everyone that Wilber, our IRC bot, has the Meetbot plugin installed: http://meetbot.debian.net/Manual.html Using it more frequently would make even small, rather informal meetings with all of their action items, agreements and disagreements easier to record. -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hello, On Sat, Apr 2, 2016 at 12:18 AM, Andrew Toskin wrote: > > >> On 2016-04-01 13:32, Pat David wrote: >> >> 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). > > Whether or not we can get plugin developers to follow it, separating > scripts and plugins into different repositories seems like a good > recommendation, for a number of reasons. For plugin and script authors, > it would make managing bugs and user feedback easier. For end users, > it's also annoying to clone a large repository when you're only > interested in a small subset of its contents. If authors are really > going to lump together their plugins and scripts, we could at least > recommend that they try to only group together the things that are most > closely related. Create several smaller collections of scripts, instead > of one giant collection. Exactly. Some people like to create huge collections of scripts. G'Mic comes to mind. They will obviously continue to do so anyway. I personally prefer to install only the scripts I need (and not 100 others which would come with). Well then some scripts are closely related and it would make sense to have these together. Why not. There are many cases. In the end though, every content creator is free though. My point is not to enforce a style of plugin creation. The point was to make the equivalency: 1 repository = 1 extension. What I call "extension" here is a 1-time download item. It can be a python plugin, a GimpFu script, a collection of brushes, a theme or an icon theme, patterns, whatever which can be installed in GIMP. It can be 1 single script, as 100 scripts, or a mix of contents. Plugin developers are free to do whatever they want. They just have to know that 1 repo = 1 extension. So when a user clicks "Install", the user installs the whole extension, be it just 1 script or a whole collection of 1000 scripts. In this repo, they would have a README in the root directory, which will be used to generate the extension description. I think this is much better than trying to develop a metadata format where a plugin developer would have to organize one's plugins in a complex subdirectory structure. Of course, a plugin developer could always go the basic way: uploading an archive for new releases. I would imagine that developers who already have their own organization and their repository somewhere may prefer to keep this way. The repository proposition is only meant as a bonus for plugin developers who would not know where to host their code. We could tell them: hey, just let us host your code if you want. Which will incidentally help for integration (releases could be done by tagging a commit, etc.). Just wanted to make the idea clear. Jehan -- 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
Re: [Gimp-web] [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-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Hi, On Fri, Apr 1, 2016 at 11:41 PM, Andrew Toskin wrote: > > > 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. The discussion is not about core GIMP and I don't think there are any advantages in migrating GIMP out of GNOME infrastructure. I mean, if there were several long-term contributors willing to maintain our own infrastructure, and which we can trust to not disappear in a few months, why not. And even so, I'm not sure what would be the gain there. Bugzilla works very well, in my opinion. The patch process is like 100x better than the weird fork logics that github imposes. And I don't see anything in the web UI that I can't do 1000x better in my terminal. Anyway this thread is about plugins and since there is nearly no chance for GIMP migrating to a gitlab hosting, let's not diverge the topic. Thanks. Jehan > ~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
Re: [Gimp-web] [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
Re: [Gimp-web] [Gimp-developer] Gitlab as a replacement for registry.gimp.org
On 1 April 2016 at 18:14, Kasim Ahmic wrote: > I personally am a huge supporter of redoing the registry, and I like the > ideas you've proposed here. My only concern is one that was actually brought > up by someone else a few months ago; registry integration within GIMP and the > possibility of viruses. > > I don't quite remember who mentioned it, but they brought up that registry > integration within GIMP itself could potentially open the doors to viruses > unless a virus detection feature was built into GIMP as well. Now, I'm not > entirely sure how true this is but I would like to hear a final say on this > whether this is an actual issue or not. > > If it is an issue, what would be the best way to handle it? I'd imagine that > building virus scanning within GIMP would take quite a long time and be > pretty impractical. As such, I would suggest that we go with a self hosted > solution so that we could incorporate a virus scanner on there to scan all > the uploaded assets. Either that, or a hosted solution like GitLab that come > with a virus scanning option along with it. > > Again, not sure how much of an issue this even is. Just a thought. So - this would be one of the main purposes of a "curation" - Only non-malicious assets would be made available as "safe" from the server-side. Having security features on the client side (i.e. on the computer of the person running GIMP), is not feasible: one single line of code in a rogue plug-in can wipe the user harddrive. . Assuring assets are safe, even if few, and can't be maliciously modified, in the repository is hard enough - but can be done. The hard-to-balance thing is allowing publication of assets by a large amount of people, and having process/volunteers to ensure these assets are safe. Either way, I think the download and install should be done with a few clicks from wthin GIMP itself - we don't have to burden users to locate the file in a browser, download it, copy it to the right folder, set its file properties if that is not needed. If the assets represent a danger, they will represent an equal danger in this "manual way". > > - Kasim Ahmić > > Sent from my iPhone > >> On Apr 1, 2016, at 4:32 PM, 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