[PD-dev] moving to git? (was Re: Pd-dev Digest, Vol 124, Issue 2)

Fred Jan Kraan fjkraan at xs4all.nl
Fri Jul 31 00:10:01 CEST 2015


Hi IOhannes,

Thanks for the writeup and the work already done preparing the svn-git
migration. I expect to migrate the cyclone stuff later this year, but
have to decide the location.

For cyclone I foresee two variants; the common separate object set and a
Max/MSP 4.x migration set, with maxmode and library objects. The latter
was the original distribution as created by Krzysztof Czaja.


Greetings,

Fred Jan

On 2015-07-30 11:05 AM, IOhannes m zmoelnig wrote:
> 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
> 
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev
> 



More information about the Pd-dev mailing list