On 07/08/15 04:27, Jonathan Wilkes via Pd-dev wrote:
I now have a gitlab instance up and running, hosted by Oregan State University Open Source Labs.
I'm currently using it for the GUI port, but I set it up specifically to migrate away from Sourceforge (as well as not having to rely on yet another commercial service with the same business model).
Support was nice enough to help me set up a cert for logging in over https. That's just a stop-gap-- something like git.puredata.info or gitlab.puredata.info would be preferable. (That would require an additional cert for the subdomain, something which startssl doesn't allow.
i've been pondering about all this for long, and the recent outage of sourceforge gave more pressure to it. sf is back up again, so we now have at least a recent enought backup of the entire tree :-).
thanks jonathan for taking the initiative.
my personal opinion on all this is:
#1 we should move to a decentralized VCS, namely git #2 we should make use of the decentralized nature of such a VCS #3 for this we need a history preserving transition plan #4 we also would need a general transition plan
some notes:
ad #1 i'm mainly suggesting git as this is currently (still) all the hype, (almost) everybody i work with is using it; and Pd-vanilla and Pd-extended and Pd-l2ork already switched to it, so it seems that natural choice.
ad #3 i really would like to split that huge repository into small projects (mainly: per-library). i've already started working on this on [1], which is nothing much to show yet, but in the end it should document the process and provide a way to re-play the conversion.
i currently think that it's insane to convert the entire repository. there is way too much cruft in there, starting from CVS-tags meant for simple externals but covering the entire tree. there is about an unknownbyte of 3rd party libraries included in /sources, each of them required by only a few externals. there are a number of externals that have seen their EOL a while ago and won't be touched in the foreseeable future. some have been deleted from the SVN.
i see little gain in converting all those to git.
#4 ah yes; i haven't thought about that too much yet.
one problem i see is that there are still a number of externals using the externals/Makefile for building rather than being self-contained (e.g. using the template/Makefile; or katja's pd-lib-builder) but hey, this could be *the* opportunity to push the use of pdlibbuilder!
a switch will obviously break a number of things, like the auto-builds and the entirety of the pd-extended system. i don't think that pd-extended as a whole package should be migrated (in a history preserving fashion, using automated tools to extract from the svn repo): instead it should be re-setup (if needed), using git-submodules and the like.
then finally, this would require a coordinated switch with freezing the svn (again, like back in the cvs2svn days)
#2 so where to host it? as much as i welcome jonathan's offer, i'm not seeing clear what this means in terms of long-term availability. OSUOSLs track record [2] is impressive, but as i haven't worked with them yet, i don't know how this will evolve over the years.
in my experience, when it comes to (smallish, like Pd) FLOSS projects, if hosting is done by a non-commercial institution, then the long-term support usually depends on humans from the community, who actually run the project (in practice i find it most often to be single persons rather than groups). as soon as the humans in charge are leaving the project (finished their studies; got kids; pissed off by the way the community works; ...) those services usually die away.
with "long-term" i'm talking about >>10 years. i still remember the pdpedia, which shone bright and was gone rather soon. i would prefer this wouldn't happen to the sources.
these might all be non-issues with OSUOSL, but i simply cannot tell. (i have to admit that only today i found the time to skim through the hosted projects, and it *is* impressive).
in any case, i thought that it might be better to really allow the devs themselves to pick *any* hoster they prefer, be it your own gitlab instance, OSUOSL, github, or even sf. in that case, git.puredata.info might be simply a portal to the various git-servers. e.g. providing a central webpage that lists all those repositories, wherever they are.
migratory repositories: additionally we could do some proxying, so that the user doesn't need to track the current authoritative git-server for a given repository (the repo admin would need to tell the proxy system when they have moved the repo; but all the URLs would stay the same from the user perspective). e.g. you can currently use [3] to clone deken from github; in a year it might pull from OSUOSL.
mfgasdr IOhannes
[1] https://github.com/umlaeute/pd-svn2git [2] http://osuosl.org/communities [3] http://git.puredata.info/proxy/pure-data/deken