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 <patdavid@xxxxxxxxx> 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 with assets, or > repository with multiple assets contained inside. Importantly, the > submodule can be a completely different git repository owned by someone > else (and is basically it's own git repo with logs, etc...). > > So, in this approach, the "Registry 2.0" repo by itself can contain: > > 1. Assets > 2. Submodules > a. Single repository of an asset > b. Single repository of multiple assets (not necessarily owned by us) > > (I also just realized that this idea could be considered a _super_set of > what Jehan wants in single repo = single asset). > > The important thing for supporting an installer in the future is a way to > enumerate the list of available assets contained inside the repo. I was > personally thinking some sort of "Asset Index" file to point to all of the > relevant assets for automation. [1] > > What's nice about this approach is that we can house assets ourselves in > the main repo, house assets in other repos ourselves, or we can link in > other authors assets as submodules. > > > > Single Account > ---------------------- > The approach as I understand it from Jehan for a single repository = single > asset would look something like this: > > [image: account-full.png] > [account-full.png] > https://gitlab.com/GIMP/GIMP-Scripts/raw/master/ideas/account-full.png > > In this case, the account would contain multiple git repos, with 1:1 > mapping between asset:repository. > > One of the problems I can see with this approach is: > > 1. A full git repo for a single .scm file seems like overkill? Why? Do we absolutely need to fill emptiness? :-) > 2. Asset authors would _have_ to use our git repo (or would have to sync to > them when they wanted to push something new). No. As I said, the base of the base, the first feature of any plugin system is: uploading tarball/zip archives of the plugin. No plugin system should force the developer to use a specific repository. Maybe you don't even want to use git at all! Who are we to judge? Wordpress provides source repository to plugin developers, but you can always just upload a zip when you want to make a release. Most other plugin system work only like this (last I checked, I don't think that Mozilla provides any kind of code repository to plugin developers). The source code repository should be a bonus. It should not be the main feature. This is what I said in my previous email already. So no, you don't have to sync your repo. If you want to host it somewhere else, just fine. Absolutely no problem with me. Just upload archives when you want to make a release. This has not stopped dozens of software out there to have thousands of plugins. Everybody knows how to upload a file. > 3. Will we hit a limit to the number of repos allowed per account? (Not > sure - can't find hard numbers on this at gitlab). Since we would be using our own gitlab, how could we be hitting an account limit (we would set these ourselves)? Unless these are limits in the code, which are usually int type limit, but then if we reach such limit, there are probably more problems than reaching account limits. I don't think there are any person out there who will write thousands of plugins for GIMP single-handedly. :-) > [1] Asset Index > ---------------------- > Regardless of which approach is used, the main question is what type of > index mechanism might have to be created to support an "Asset Installer" > later. It may be possible to run a CI script that scrapes relevant data > from the metadata of each asset in a standard formatted way to supply the > relevant information for the installer? I'm honestly not 100% sure here > and would welcome any feedback on the possibility or implementation. This is absolutely not a problem. Have you had a look at software management system on Linux? Well what we will do will be the same. We will simply have a database of plugin information (this database is usually in the form of a single file for package management systems, which you download before showing the list of available software) which can be requested by GIMP, when the user wants to see the list of available plugins. Since such a database can be updated close to real-time, the user always have close to current information. Here for instance, here is what looks like a Fedora repository: http://mirrors.ircam.fr/pub/fedora/linux/releases/23/Everything/x86_64/os/ Inside repodata/, you've got the database files of everything which is in the repository. It gives you the name, descriptions, etc. everything about packages and where to download them. The Fedora package management system would simply download these information (that takes just a few seconds) to be able to present available software to the user. An alternative could be some kind of web API, but this could be a little more resource-hungry than the previous system (you are constantly querying the server, but on the other side you are asking for less information, so less wait. It may be a better user experience actually), which is likely why package management system don't go that way. This is a possibility though, and actually I have been considering it seriously. As for the format of the metadata, that's not much of a problem either. I even have a few sample somewhere of what could be the metadata file for a GIMP plugin, as well as some files listing contents of such a metadata file. The point is that there are many good plugin systems out there, and we can just look at them. The format itself is just a matter of choosing one format and sticking to it. Then we have to choose what data goes in. But this is not that hard either. In any case, no these are not a problem at all, and only of technical matter. This is the easy part. > Implementation > =========== > At the moment there is a freeze on rgo. No new assets are being shared > there. > > I can start walking through the archives now and begin the process of > uploading the relevant information from assets that look like they might be > worth the effort (with input from other folks that know about these things > far better than I <cough>akk<cough>). > > Please, I am not on 100% firm footing with some of these ideas, I'm simply > experimenting and reading docs to understand better what might be available > to us, so don't hesitate to let me know if I'm off my rocker or completely > off track on some of these thoughts. > > I think this is something worth meeting and discussing face-to-face at LGM > as well, if everyone wanted to set aside a little bit of time to hash it > out. Yes. In any case, I think this will be my last message on this topic before LGM. I have too many things to take care about first. Thanks. Jehan > -- > Pat David > https://pixls.us > http://blog.patdavid.net > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@xxxxxxxxx > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
