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

[IOhannes m zmoelnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150730/77eaf468/attachment.sig>