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 <akkana@xxxxxxxxxxxxxx> 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 GIMP if we had a hosting system). A plugin can be a single file, yes, but it can also be dozens of files for very complex plugins. And yes, Wordpress is successful. Last count, it was like more than 20% of the world websites. The most popular CMS of the world. > 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. Aaaaargh! And this is the part where you have not read what I have said countless and countless of times in previous emails. So basically you have read none of my emails fully! You even dare say you have had no answer to somewhere I explicitly answered yesterday (and that's in the exact email you are answering to)! How crazy is that? Let me quote myself from my previous email: > Since we would be using our own gitlab, how could we be hitting an account limit (we would set these ourselves)? And from my email before that: > For me, this is better to just stick to tarball plugins if we cannot host our own controlled repository service. And from another email before that: > 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 And so on. I didn't even quote fully. Each of the quotes were partial to, and I explain in details my thoughts about the topic in the said emails. So you really cannot say I have not answered these! No, we won't check out repositories (I even gave the example of a service, OpenHub, which does checkout repositories for statistics, and that makes it slow to update. We don't want this!). And no we won't maintain third-party plugins! Mozilla does not maintain the thousands of user-contributed Firefox plugins. Automattic neither for all Wordpress plugins. We should make sure they are not malevolent or dangerous (and there can be various ways to ensure this) but that's it, not maintain them! And we won't have any account limit problem (my previous email had the answer to this exact question!). I have answered already to all of these points! Can you imagine how frustrating it is for me to read a contradiction to my proposition with parts showing you actually didn't read the full of it? Do you think I didn't read your email fully before answering? That would be pretty disrespectful. Now I don't want to look like I am pissed or something. Well I am a little, because I felt like I lost some of my time these last days repeating myself and feeling like nobody read my emails even though I was asked personally to answer. But anyway in the end, that's still technical discussions, and it made me think a little about the possibility of collections of plugins which can be separated into individual plugins. So some users who just want as much as possible and don't have time being choosy would just install the whole collection, whereas others could install them individually. So we could have a collection "Old Photograph" with a bunch of scripts related to processing old photographs. You could still install scripts individually, and if later you were to install the "Old Photograph" collection, any script from the collection already installed would not get installed a second time. I don't think that it would change the 1 plugin = 1 repo paradigm though. This would be more like tagging. For instance a single script could belong to several collections (which would not be possible if we decided a collection would be one repo with several plugins). Also a collection could contain plugins that you don't maintain for instance (this is also not possible if a collection were a repo). And no, before anyone proposes, using submodules is not an acceptable solution since a plugins would be installed several times if you installed several collections including it. I don't want to overdesign the plugin metadata format with sub-plugins in subfolders or other crazy features before it even exists. Anyway I'm still thinking of the idea of developer-side collections while having separate user-side plugins while keeping it simple conceptually. So I can still change my mind. But just please, read my emails before answering, next time. ;-) > 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.) I hope so! We need contributors for pretty much everything GIMP-related, even more skilled ones like you. Will you be at LGM? We would be able to speak of this, with Patrick and anyone interested, in better conditions than by email. Jehan > ...Akkana > _______________________________________________ > 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
