Re: [Gimp-web] Gitlab as a replacement for registry.gimp.org
Hi Sven! On Mon, Apr 4, 2016 at 2:36 PM Sven Claussner wrote: > One problem of the current registry (before it was broken) > is that there are compiled plug-ins for just one platform, > e.g. Win32, if compiled at all. > Therefore users of other or newer platforms, e.g. OS X, > either have to compile it on their own or simply can't use it. > This is an overload to non-developing users. > I thought it it's a good idea to provide plug-in builds for all > relevant platform at a single, central address. > Each asset should have it's own folder there, such as > $hoster/gimp-registry/plug-ins/$plug-in > This makes it easy for users as well as the asset browser and > downloader component in GIMP to browse and find assets. > I don't want to promise too much, but perhaps it could > be integrated into our Jenkins CI system one day and then > it's easier to generate jobs for the plug-in builds, too. > I'm honestly not sure what the best path may be in this instance. Certainly CI builds for the major platforms would be awesome, though. > > I'm not sure whether it's a good idea to rely on private Git > hosting provider like Gitlab. If they started going the Sourceforge.net > way we had to move again. Does the GNOME infrastructure deliver > something appropriate, too? > This is a fair concern. I can only say that in this case GitLab itself is a free software project ( https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE - MIT License). We can host the infrastructure on our own servers if we need to. If everyone feels we are better off on GNOME infrastructure, I'm all ears if we can try to keep a similar level of accessibility for users. -- 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] Gitlab as a replacement for registry.gimp.org
Hi, I didn't follow the whole discussion so I hope to not repeat things that were already said. One problem of the current registry (before it was broken) is that there are compiled plug-ins for just one platform, e.g. Win32, if compiled at all. Therefore users of other or newer platforms, e.g. OS X, either have to compile it on their own or simply can't use it. This is an overload to non-developing users. I thought it it's a good idea to provide plug-in builds for all relevant platform at a single, central address. Each asset should have it's own folder there, such as $hoster/gimp-registry/plug-ins/$plug-in This makes it easy for users as well as the asset browser and downloader component in GIMP to browse and find assets. I don't want to promise too much, but perhaps it could be integrated into our Jenkins CI system one day and then it's easier to generate jobs for the plug-in builds, too. I'm not sure whether it's a good idea to rely on private Git hosting provider like Gitlab. If they started going the Sourceforge.net way we had to move again. Does the GNOME infrastructure deliver something appropriate, too? Greetings Sven ___ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] Gitlab as a replacement for registry.gimp.org
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, assuming they'd even let me create that many repos; it makes it hard 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). > For end users, > it's also annoying to clone a large repository when you're only > interested in a small subset of its contents. That's true. But nobody's suggesting that end users would be cloning git repos, are they? They'd just be running some friendly UI to say "give me the files I need for the foo plugin", and the backend downloads the right files and puts them in the right place. End users will never know they're using git at all. ...Akkana ___ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] Gitlab as a replacement for registry.gimp.org
> 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. ___ gimp-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
Re: [Gimp-web] Gitlab as a replacement for registry.gimp.org
I rather like GitLab, and this seems like at least as good a solution for a plugin registry as any other solution we've considered so far. In fact, I think GitLab (or some similar solution) would also be a major improvement for tracking the core GIMP software. As an occasional contributor just to the documentation, I find Bugzilla, and the process of creating and uploading patch files, cumbersome and weirdly old-fashioned. GitLab could do everything Bugzilla or cgit can, and much more, _and_ it's got a much better UI and workflow. ~Andrew On 2016-04-01 13:32, Pat David wrote: > Continuing on some discussions from irc... > > Registry.gimp.org is down for the count. > > I was thinking recently about some ideas for a possible replacement. > Mostly thinking along the lines of what made the registry work well for > folks. > > In the rest of this email, I'll use the term "asset(s)" to refer to things > like plug-ins, scripts, or brushes/gradients/curves/other assets. > > Some essential functionality based on the old registry drupal instance: > > 1. Upload/Download assets for GIMP. > 2. Describe the asset (usually by the uploader). > 3. Comment on the assets. > > This was handled previously by using drupal, which treated each entry as a > post/node that included the ability to upload files, write about the files > as a post, and had comment threads below it. > > Keeping this functionality would be good, I think. The ability to post an > asset is a given, but the ability to interact around it helps foster the > community (and provides nice feedback for the authors). > > From those thoughts, what would be nice to have in a replacement: > > 1. Provide at least the same previous functionality (as listed above). > 2. Managed or easier to manage and keep updated. > 3. Easier account management. > 4. Collaborative environment for shared assets > 5. Support possible GIMP integration in the future (one-click asset > install?). > > GitLab? > == > > Initially, I had thought Github might be a good option for this but given > its closed-source nature decided to investigate something like GitLab > instead. > > I like this idea personally due to some nice infrastructure: > > 1. The service is hosted + managed (and available as Free Software just in > case we felt we needed to break out and host it ourselves). > 2. The service integrates OAuth sign-in using a few different account types > (lowers barrier to entry to participate). > a. they use accounts, Google, Twitter, Github, or bitbucket accounts > for sign-in. > 3. Projects maintain all the git-goodness for control and tracking > 4. Projects created as a git project can have a full description/README > along with issue tracking integrated in the site > > So, we can fulfill the original registry functionality and get the added > benefit of a git infrastructure for those wanting to contribute, user > accounts using OAuth to make it easy to participate, and the ability to do > some interesting things (git submodules). > > In speaking with Jehan about this, we should also consider what might be > needed to support the ability to install assets from within GIMP in the > future easily. > > Organization > = > > Jehan suggested that each script/plugin/asset have it's own git repo. > This would be handy, particularly if script authors did this as well (as it > considerably eases the inclusion of external repos as submodules). > However, akk points out that many folks don't (won't?) organize their repos > in this way (it gets a little... unwieldy pretty quickly if you have many > scripts). > > I'd like some input on what would make the most sense or work best for > possible organization of repos. > > I was also thinking that we could include some simple metadata in both any > script files and the README.md files as a means to possibly help parsing > relevant information for automated inclusion at a later date (GIMP plug-ins > installer type of idea). > > Curation > == > > Initially I was thinking that curating the scripts for inclusion would be > important. It's certainly possible for a smaller subset of all of the > available scripts from the registry now to pick out ones that we use and > check that they're not malicious and properly tagged/included. For > instance, there's a handful of scripts that I personally find myself using > often and can help validate/curate for inclusion. I don't mind doing more > as needed. > > I just wanted to get a discussion started about how we might consider > moving forward on something like this. I think the scripts/plug-ins are > important enough to users that it would be good to try and get something up > and running soon. > > I have started experimenting with including submodules from other author > repos and how it might look here: > > https://gitlab.com/GIMP/GIMP-Scripts/tree/master [1] > > I look forward to hearing some thoughts on this! > > pat Links: -- [1] https://gitlab.com/GIMP/G
Re: [Gimp-web] Gitlab as a replacement for registry.gimp.org
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. - 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 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 a
[Gimp-web] 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-web-list mailing list gimp-web-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-web-list
