Hi, On Mon, Apr 4, 2016 at 2:50 AM, Akkana Peck <akkana@xxxxxxxxxxxxxx> 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 exactly a perfect example of why github workflow basically broke a sane git workflow! >> 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. Indeed. End users won't even use git at all. We are not going to add git as a dependency for GIMP just to install plugins! Plugins will be downloaded (probably in https, a protocol which don't need additional dependency to be available everywhere). The git discussion is only for developer side. To be clear, I would never have started from this topic. This is already an optional feature (as said, the basic feature is just being able to upload a zip/tarball of your plugin). What really matters at first, is having a sane installation workflow and new extension format (not a complete new format. It would be based off what we have, but with additional metadata, to handle description, versionning, etc. I already have a sample of this — somewhere in my computer — that I had been working on more than a year ago, based off various other extension formats for other software out there). 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
