This is exactly what we were *nudging* for. It's not a movement against, just a growing process. The SVN has served it's purpose but now a more decentralized approach works since the tools and dev approach have changed.
I created the "pure-data" GH group as an umbrella for this kind of development, so we could think about moving generally useful & actively support externals there. Then anyone can do a PR or be given externals development access via GH groups, etc without worrying about "stepping on anyones toes" or being stuck with something on their personal account. Original authors, of course, are free to take over their own projects and move them if they want, but there are definitely cases of externals which have become more community developed.
A centralized SVN repository with all externals in it seems like it has
been a point of friction in the Pd development ecosystem.
You could set up your stuff in Github repositories, and if somebody wants to continue to use SVN and also wants your fixes then they can figure out how to merge them back. I would make contact with people who are doing packaging of the externals for distributions and tell them that you have versions of those externals with newer modifications and they can decide whether to continue to use the SVN version or your newer versions with changes.
Hm, maybe this is too aggressive a strategy, I don't know.
In any case, I don't think there is anything inherently wrong with forking code and putting it in a Github repository and making improvements. That's basically the whole point of FLOSS. Then if people want to use your new versions, great.
On 07/07/2015 10:15 AM, Dan Wilcox wrote:
This is exactly what we were *nudging* for. It's not a movement against, just a growing process. The SVN has served it's purpose but now a more decentralized approach works since the tools and dev approach have changed.
I created the "pure-data" GH group as an umbrella for this kind of development, so we could think about moving generally useful & actively support externals there. Then anyone can do a PR or be given externals development access via GH groups, etc without worrying about "stepping on anyones toes" or being stuck with something on their personal account. Original authors, of course, are free to take over their own projects and move them if they want, but there are definitely cases of externals which have become more community developed.
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. But once EFF's "Let's Encrypt" project ships we can get additional certs trivially.)
If anyone wants to play around with it, PM me and I'll send a link.
-Jonathan
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
Btw-- could you make Gem a priority? It appears it's already in git. And since it's fairly self-contained migrating it doesn't come with all the issues of (dis)organization that splitting up Pd-extended svn does. Also-- what do we do with the binaries that are currently on Sourceforge?Can we eventually delete them? Can we "release" another binary that justprints out a warning that this is no longer the official Pd repository? If the most recent Pd-extended binary on Sourceforge gets forgotten over the next 10 years, it will get bundled with malware, users will download it, and those users will be harmed. -Jonathan
On Thursday, July 30, 2015 5:07 AM, IOhannes m zmoelnig zmoelnig@iem.at 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@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 07/30/2015 06:46 PM, Jonathan Wilkes via Pd-dev wrote:
Btw-- could you make Gem a priority? It appears it's already in git.
not sure i understand what it is you want me to do with Gem. Gem has switched to git 4 years ago (history preserving), and is currently hosted on github. it also did not require much reorganisation, since it traditionally had been a single, independent repository outside the puredata repo.
gfmrdsa IOhannes
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@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 30/07/15 17:05, IOhannes m zmoelnig wrote:
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.
The good thing about this is we don't even need to "allow" anybody to do anything. As Roman showed, anybody can take the initiative and start maintaining the externals they like at this very moment.
Hopefully we see more of that, and hopefully people take Jonathan up on his hosting at OSUOSL. GitLab looks like excellent software!
Cheers,
Chris.
On 07/31/2015 04:36 AM, Chris McCormick wrote:
On 30/07/15 17:05, IOhannes m zmoelnig wrote:
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.
The good thing about this is we don't even need to "allow" anybody to do anything. As Roman showed, anybody can take the initiative and start maintaining the externals they like at this very moment.
well, everybody was always free to do that. so i probably shouldn't have used "allow".
what i'm really interested in (and which is why i put work into it), is a coordinated transition that would allow [sic!] anybody who is interested in taking part in the development process (or just interested in getting the latest and greatest sources of a given external) to find what they are looking for.
traditionally this was rather easy: Pd had a single repository where virtually all (FLOSS) libraries were aggragated. most were actively developed in that SVN (a few were regularily imported from whatever their upstream used). so if you were interested in "what's going on in Pd land", then you would just need to check out that repository.
when switching away from sf/svn we might lose this feature. did you know that i forked iemnet onto github a while ago? having s-abstractions hosted on gitlab.mccormick.com is nice, but how will anybody ever stumble (serendipitously) upon that?
worse, if you change your authoritative VCS server (even and esp. with a distributed VCS), you need to tell people when they keep reporting bugs in code that has been deprecated for years.
that's why i'm pushing towards a coordinate transition.
gfmards IOhannes
On 31 July 2015 at 19:40:32, IOhannes m zmölnig (zmoelnig@iem.at) wrote:
On 07/31/2015 04:36 AM, Chris McCormick wrote:
On 30/07/15 17:05, IOhannes m zmoelnig wrote:
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.
The good thing about this is we don't even need to "allow" anybody to do anything. As Roman showed, anybody can take the initiative and start maintaining the externals they like at this very moment.
well, everybody was always free to do that. so i probably shouldn't have used "allow".
what i'm really interested in (and which is why i put work into it), is a coordinated transition that would allow [sic!] anybody who is interested in taking part in the development process (or just interested in getting the latest and greatest sources of a given external) to find what they are looking for.
traditionally this was rather easy: Pd had a single repository where virtually all (FLOSS) libraries were aggragated. most were actively developed in that SVN (a few were regularily imported from whatever their upstream used). so if you were interested in "what's going on in Pd land", then you would just need to check out that repository.
when switching away from sf/svn we might lose this feature. did you know that i forked iemnet onto github a while ago? having s-abstractions hosted on gitlab.mccormick.com is nice, but how will anybody ever stumble (serendipitously) upon that? How about: authors / maintainers can host their externals wherever they like, but we maintain a “meta” repository on GitHub that includes all the various external [sic] repositories as git submodules…? This doesn’t entirely solve the issue of authors moving or deleting their repository, but it does at least provide a set of links so that if a repo moves, we know about it and can contact maintainers to find out new locations. It also provides a one-stop for "what's going on in Pd land” for those who want it.
Jamie
On 07/31/2015 03:15 PM, Jamie Bullock wrote:
On 31 July 2015 at 19:40:32, IOhannes m zmölnig (zmoelnig@iem.at mailto:zmoelnig@iem.at) wrote:
On 07/31/2015 04:36 AM, Chris McCormick wrote:
On 30/07/15 17:05, IOhannes m zmoelnig wrote:
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.
The good thing about this is we don't even need to "allow" anybody
to do
anything. As Roman showed, anybody can take the initiative and start maintaining the externals they like at this very moment.
well, everybody was always free to do that. so i probably shouldn't have used "allow".
what i'm really interested in (and which is why i put work into it), is a coordinated transition that would allow [sic!] anybody who is interested in taking part in the development process (or just interested in getting the latest and greatest sources of a given external) to find what they are looking for.
traditionally this was rather easy: Pd had a single repository where virtually all (FLOSS) libraries were aggragated. most were actively developed in that SVN (a few were regularily imported from whatever their upstream used). so if you were interested in "what's going on in Pd land", then you would just need to check out that repository.
when switching away from sf/svn we might lose this feature. did you know that i forked iemnet onto github a while ago? having s-abstractions hosted on gitlab.mccormick.com is nice, but how will anybody ever stumble (serendipitously) upon that?
How about: authors / maintainers can host their externals wherever they like, but we maintain a “meta” repository on GitHub that includes all the various external [sic] repositories as git submodules…?
And why do you prefer Github to Sourceforge? What's different enough in their business model that there is no inherent conflict between serving the free software community on the one hand and monetizing their users/userdata on the other?
-Jonathan
On 07/31/2015 10:12 PM, Jonathan Wilkes via Pd-dev wrote:
On 07/31/2015 03:15 PM, Jamie Bullock wrote:
How about: authors / maintainers can host their externals wherever they like, but we maintain a “meta” repository on GitHub that includes all the various external [sic] repositories as git submodules…?
And why do you prefer Github to Sourceforge?
s/GitHub/git.puredata.info/
i don't think that jamie's point was to propose GitHub, but rather a central point that would reference the various repositories. it could be a gitweb instance running on http://git.puredata.info/ with a single admin user.
gfmards IOhannes
On 31 July 2015 at 21:24:29, IOhannes m zmölnig (zmoelnig@iem.at) wrote:
On 07/31/2015 10:12 PM, Jonathan Wilkes via Pd-dev wrote:
On 07/31/2015 03:15 PM, Jamie Bullock wrote:
How about: authors / maintainers can host their externals wherever they like, but we maintain a “meta” repository on GitHub that includes all the various external [sic] repositories as git submodules…?
And why do you prefer Github to Sourceforge?
s/GitHub/git.puredata.info/
i don't think that jamie's point was to propose GitHub, but rather a central point that would reference the various repositories. it could be a gitweb instance running on http://git.puredata.info/ with a single admin user.
That’s correct, I just used GitHub in example as it had been mentioned earlier in the thread.
(Although... I do prefer GitHub for my own projects as I find the UX to be far better than sf.net. I’m not proposing we use it for Pd, as clearly there are other factors and priorities to consider.)
best,
Jamie
On 07/31/2015 04:23 PM, IOhannes m zmölnig wrote:
On 07/31/2015 10:12 PM, Jonathan Wilkes via Pd-dev wrote:
On 07/31/2015 03:15 PM, Jamie Bullock wrote:
How about: authors / maintainers can host their externals wherever they like, but we maintain a “meta” repository on GitHub that includes all the various external [sic] repositories as git submodules…?
And why do you prefer Github to Sourceforge?
s/GitHub/git.puredata.info/
i don't think that jamie's point was to propose GitHub, but rather a central point that would reference the various repositories.
I'm not getting the point of all this. If you require a central point to reference the random collection of repos for the purpose of discoverability and sanity (and you _do_ require a central point for both), why go to the trouble of decentralizing the central repo?
In the original scheme I would just keep bothering you or Hans to give commit access to someone wanting to adopt an external lib. In the new scheme will I just keep bothering you until you add a reference to the centralized list?
-Jonathan
it could be a gitweb instance running on http://git.puredata.info/ with a single admin user.
gfmards IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 2015-08-06 15:54, Jonathan Wilkes via Pd-dev wrote:
In the original scheme I would just keep bothering you or Hans to give commit access to someone wanting to adopt an external lib. In the new scheme will I just keep bothering you until you add a reference to the centralized list?
yes.
the difference is, that with the new scheme you can start working immediately and if I'm busy/on vacation/switching to supercollider or just being a general dickhead doesn't really matter.
from the developer perspective, the centralized repo is just a means of reaching an audience. i believe that the "moderator" for this announcment channel should not be bothered with managing the *actual* repositories (where the code development happens).
fgamdr IOhannes
On 01/08/15 04:12, Jonathan Wilkes via Pd-dev wrote:
And why do you prefer Github to Sourceforge? What's different enough in their business model that there is no inherent conflict between serving the free software community on the one hand and monetizing their users/userdata on the other?
"...GitHub has been called the 'Facebook for developers'..."
http://www.wsj.com/article_email/github-raises-250-million-at-2-billion-valu...
-_-
I still can't get gittorrent working properly, but I'm continuing to try. Hopefully it will mature.
Chris.
Ha ha:
https://github.com/amoffat/masquerade/commit/9b0562595cc479ac8696110cb0a2d33...
Chris.
On 01/08/2015, at 11:59, Chris McCormick chris@mccormick.cx wrote:
On 01/08/15 04:12, Jonathan Wilkes via Pd-dev wrote:
And why do you prefer Github to Sourceforge? What's different enough in their business model that there is no inherent conflict between serving the free software community on the one hand and monetizing their users/userdata on the other?
"...GitHub has been called the 'Facebook for developers'..."
http://www.wsj.com/article_email/github-raises-250-million-at-2-billion-valu...
-_-
I still can't get gittorrent working properly, but I'm continuing to try. Hopefully it will mature.
Chris.
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
I assume Linus would be slightly suspicious getting a pull request from himself. :)
But in cases where there's no obvious hierarchy for new users to enter the network, oversights like these are surely dangerous. Unfortunately the free software community infrastructure has the same issues-- 1) download all the public GPG keystores 2) count the total number of keys3) generate that same number of keys, copying the name/email info you got from the keys in the keystore 4) graft the social graph (i.e., which keys signed which other keys) from the keystores onto the keys you generated, creating a kind of "shadow" keychain5) slowly upload your "shadow" keychain back up to the public GPG keystores. Voila! Now you have two Richard Stallmans, two IOhanneses, two everything. Big deal. But you also have the _exact_ same number of signatures on each key as the real keychain. To the newcomer its impossible to tell which is real and which is fake by counting the signatures. I mentioned this to some GPG gurus, and they brushed it off because-- after all-- the "shadow" keychain just sits there on its own little island. And that's true, until somebody accidentally signs something in the "shadow" keychain from the real one. (I also watched a video of a security expert mentioning this same issue, which was alarming because I had always assumed I didn't understand well enough how the web of trust works...)
-Jonathan
On Tuesday, August 4, 2015 8:59 PM, Chris McCormick chris@mccormick.cx wrote:
Ha ha: https://github.com/amoffat/masquerade/commit/9b0562595cc479ac8696110cb0a2d33...
Chris. --http://mccormick.cx/ On 01/08/2015, at 11:59, Chris McCormick chris@mccormick.cx wrote:
On 01/08/15 04:12, Jonathan Wilkes via Pd-dev wrote:
And why do you prefer Github to Sourceforge? What's different enough in
their business model that there is no inherent conflict between serving
the free software
community on the one hand and monetizing their users/userdata on the other?
"...GitHub has been called the 'Facebook for developers'..."
http://www.wsj.com/article_email/github-raises-250-million-at-2-billion-valu...
-_-
I still can't get gittorrent working properly, but I'm continuing to try. Hopefully it will mature.
Chris.
On 2015-07-30 11:05, IOhannes m zmoelnig wrote:
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.
so i've done a first transition.
all the git-repositories can be found at
http://git.puredata.info/cgit/svn2git/
they are browsable and can be cloned directly from the webpage. however, these repos are meant as starting points, so we do not provide *any write* access. so once you forked, push to your own server (or gitlab, github, sourceforge, you name it) and let us no.
the process is documented (a little bit) on [1], but some parts of the migration had to be done manually (namely the selection of the paths to base the various libraries on; and the merging/re-rooting of repositories with independent branches).
so what is it? === an automated, history preserving, migration of the current svn directory into multiple git repositories, one for each library.
# why should i use this? if anybody who wants to start working on any of the pd-repo libraries uses the same git repo as root, it is trivial to merge those changes back together. so using those repositories as starting point, should make collaboration between independent devs a lot easier (compared to, when everybody does their own conversion, or just starts off wherever they think).
# what is included? i tried to capture as many libraries as possible (even those that had been removed from the svn a while ago). i tried to only include "libraries" (addons, plugins), regardless of whether they are "abstractions", "externals", "scripts" or "gui-plugins".
# what is not included? libraries that were only included via svn:externals (thus hosted on different servers). this is mostly, Gem, gridflow and grrrr. also some other libs that were not maintained on the svn but where only added/removed a few times (without adding any real history): these turned out to be too much of a hazzle for little value.
# externals vs abtractions i did not discriminate between the two. a few libraries were split on the two directories (e.g. abstractions/footils and externals/footils) and i have taken the liberty to re-combine them ("footils.git" contains both abstractions and externals)
# what is left to do? svn2git migration wise, probably not too much. however, i haven't really checked the resulting repositories (apart from generic sanity), so there might be bugs in the migration script itself.
have fun.
gfamsdr IOhannes
As strongly and politely as I can advise: PLEASE don't pull until IOhannes implements SSL by default for these repos. While it's wise to move away from Sourceforge, it's irresponsible to force a user in the year 2015 into an insecure connection in order to do so. -Jonathan
On Wednesday, October 14, 2015 10:16 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-07-30 11:05, IOhannes m zmoelnig wrote:
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.
so i've done a first transition.
all the git-repositories can be found at
http://git.puredata.info/cgit/svn2git/
they are browsable and can be cloned directly from the webpage. however, these repos are meant as starting points, so we do not provide *any write* access. so once you forked, push to your own server (or gitlab, github, sourceforge, you name it) and let us no.
the process is documented (a little bit) on [1], but some parts of the migration had to be done manually (namely the selection of the paths to base the various libraries on; and the merging/re-rooting of repositories with independent branches).
so what is it? === an automated, history preserving, migration of the current svn directory into multiple git repositories, one for each library.
# why should i use this? if anybody who wants to start working on any of the pd-repo libraries uses the same git repo as root, it is trivial to merge those changes back together. so using those repositories as starting point, should make collaboration between independent devs a lot easier (compared to, when everybody does their own conversion, or just starts off wherever they think).
# what is included? i tried to capture as many libraries as possible (even those that had been removed from the svn a while ago). i tried to only include "libraries" (addons, plugins), regardless of whether they are "abstractions", "externals", "scripts" or "gui-plugins".
# what is not included? libraries that were only included via svn:externals (thus hosted on different servers). this is mostly, Gem, gridflow and grrrr. also some other libs that were not maintained on the svn but where only added/removed a few times (without adding any real history): these turned out to be too much of a hazzle for little value.
# externals vs abtractions i did not discriminate between the two. a few libraries were split on the two directories (e.g. abstractions/footils and externals/footils) and i have taken the liberty to re-combine them ("footils.git" contains both abstractions and externals)
# what is left to do? svn2git migration wise, probably not too much. however, i haven't really checked the resulting repositories (apart from generic sanity), so there might be bugs in the migration script itself.
have fun.
gfamsdr IOhannes
[1] https://github.com/umlaeute/pd-svn2git
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 10/14/2015 08:01 PM, Jonathan Wilkes via Pd-dev wrote:
As strongly and politely as I can advise: PLEASE don't pull until IOhannes implements SSL by default for these repos.
the only problem here is that my certificate is only valid for apt.puredata.info/puredata.info and *not* for git.puredata.info
if you can live with that, just use
https://git.puredata.info/cgit/svn2git/
gfmards IOhannes
Oh wow, I guess it's been awhile since I've used Sourceforge. It looks like they just offer svn (which isn't secure) and http by default. Yikes. It's 2015. Users should get an encrypted connection to repos by default, no exceptions. It's extraordinary to me that you'd let the limitations of StartSSL's free cert dictate the security of your users. But if that really is the limiting factor, why can't you just wait half a year for EFF's "Let's Encrypt" project to ship? Then you can get certs for however many subdomains you want, and a whole class of potential attacks on your users will disappear. In the meantime, please don't teach users that it's ok to ignore basic internet security (plus the big, red browser warnings) just because you don't feel like paying money or asking one of many capable free-software organizations for help. -Jonathan
On Wednesday, October 14, 2015 2:11 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 10/14/2015 08:01 PM, Jonathan Wilkes via Pd-dev wrote:
As strongly and politely as I can advise: PLEASE don't pull until IOhannes implements SSL by default for these repos.
the only problem here is that my certificate is only valid for apt.puredata.info/puredata.info and *not* for git.puredata.info
if you can live with that, just use
https://git.puredata.info/cgit/svn2git/
gfmards IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 2015-10-14 22:30, Jonathan Wilkes via Pd-dev wrote:
Oh wow, I guess it's been awhile since I've used Sourceforge. It looks like they just offer svn (which isn't secure) and http by default. Yikes. It's 2015. Users should get an encrypted connection to repos by default, no exceptions. It's extraordinary to me that you'd let the limitations of StartSSL's free cert dictate the security of your users. But if that really is the limiting factor, why can't you just wait half a year for EFF's "Let's Encrypt" project to ship? Then you can get certs for however many subdomains you want, and a whole class of potential attacks on your users will disappear.
whatever happens in half a year from now will happen then. we might switch to let's encrypt, use some chinese wildcard certificate or roll back to self-signed certs.
In the meantime, please don't teach users that it's ok to ignore basic internet security (plus the big, red browser warnings) just because you don't feel like paying money or asking one of many capable free-software organizations for help.
yawn. i'd rather teach people to learn the basic internet security (which is *not* about big, red browser warnings for anything as fundamentally flawed as a commercially driven certificate chain).
in the meantime you could say "thanks, for doing a lot of work".
your welcome.
fgamsdr IOhannes
On 2015-10-14 22:30, Jonathan Wilkes via Pd-dev wrote:
Oh wow, I guess it's been awhile since I've used Sourceforge. It looks like they just offer svn (which isn't secure) and http by default. Yikes.
it seems indeed a while since you've used sourceforge. you might start by reading [1]. you might as well not, in which case i would like to ask you to not spread fud.
that's not to say that i don't agree about using https anywhere (and that sf should use it by default).
fgmasdr IOhannes
[1] http://sourceforge.net/p/forge/documentation/Docs%20Home/
Oh, those are both absolutely insecure by default. You (and Sourceforge) default to insecure connections. Sourceforge only forces the encryption when the user needs to write something.
Nevertheless, I think it's cases like this one which "Let's Encrypt" is designed to solve. I'm happy to leave it to them to eventually lift the work you've done up into the 21st century.
-Jonathan
On Thursday, October 15, 2015 3:30 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-10-14 22:30, Jonathan Wilkes via Pd-dev wrote:
Oh wow, I guess it's been awhile since I've used Sourceforge. It looks like they just offer svn (which isn't secure) and http by default. Yikes.
it seems indeed a while since you've used sourceforge. you might start by reading [1]. you might as well not, in which case i would like to ask you to not spread fud.
that's not to say that i don't agree about using https anywhere (and that sf should use it by default).
fgmasdr IOhannes
[1] http://sourceforge.net/p/forge/documentation/Docs%20Home/
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 10/16/2015 12:24 AM, Jonathan Wilkes via Pd-dev wrote:
Oh, those are both absolutely insecure by default.
"both"?
You (and Sourceforge) default to insecure connections. Sourceforge only forces the encryption when the user needs to write something.
Nevertheless, I think it's cases like this one which "Let's Encrypt" is designed to solve. I'm happy to leave it to them to eventually lift the work you've done up into the 21st century.
rather than keep on ranting, you could have just cloned the repositories via https (after checking the BIG RED WARNING and assuring that it indeed is a valid certificate from a trusted party that just happens to use the wrong hostname) into your super-secret gitlab instance at OSUOSL which does everything better and not only uses cryptography but also 21st century steganography to protect everybody's privacy.
fgmard IOhannes
So you've imported all Pd libraries from svn into git, preserving commit history... great initiative IOhannes! And it is hosted by IEM, couldn't be better.
What is your idea, should all maintainers immediately stop committing to SVN, and fork their libraries to git repositories?
Some libraries don't have their own build system, but instead rely on the externals root makefile in Pd-extended SVN. Maintainers in need of a multi-platform helper makefile could consider https://github.com/pure-data/pd-lib-builder.
Katja
On Wed, Oct 14, 2015 at 4:15 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-07-30 11:05, IOhannes m zmoelnig wrote:
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.
so i've done a first transition.
all the git-repositories can be found at
http://git.puredata.info/cgit/svn2git/
they are browsable and can be cloned directly from the webpage. however, these repos are meant as starting points, so we do not provide *any write* access. so once you forked, push to your own server (or gitlab, github, sourceforge, you name it) and let us no.
the process is documented (a little bit) on [1], but some parts of the migration had to be done manually (namely the selection of the paths to base the various libraries on; and the merging/re-rooting of repositories with independent branches).
so what is it?
an automated, history preserving, migration of the current svn directory into multiple git repositories, one for each library.
# why should i use this? if anybody who wants to start working on any of the pd-repo libraries uses the same git repo as root, it is trivial to merge those changes back together. so using those repositories as starting point, should make collaboration between independent devs a lot easier (compared to, when everybody does their own conversion, or just starts off wherever they think).
# what is included? i tried to capture as many libraries as possible (even those that had been removed from the svn a while ago). i tried to only include "libraries" (addons, plugins), regardless of whether they are "abstractions", "externals", "scripts" or "gui-plugins".
# what is not included? libraries that were only included via svn:externals (thus hosted on different servers). this is mostly, Gem, gridflow and grrrr. also some other libs that were not maintained on the svn but where only added/removed a few times (without adding any real history): these turned out to be too much of a hazzle for little value.
# externals vs abtractions i did not discriminate between the two. a few libraries were split on the two directories (e.g. abstractions/footils and externals/footils) and i have taken the liberty to re-combine them ("footils.git" contains both abstractions and externals)
# what is left to do? svn2git migration wise, probably not too much. however, i haven't really checked the resulting repositories (apart from generic sanity), so there might be bugs in the migration script itself.
have fun.
gfamsdr IOhannes
[1] https://github.com/umlaeute/pd-svn2git
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 2015-10-14 21:59, katja wrote:
So you've imported all Pd libraries from svn into git, preserving commit history... great initiative IOhannes! And it is hosted by IEM, couldn't be better.
What is your idea, should all maintainers immediately stop committing to SVN, and fork their libraries to git repositories?
i think the idea is to let the devs choose. if someone prefers to work with svn, so be it. if somebody else prefers gi, then they have now a history-preserving base repo to fork from.
Some libraries don't have their own build system, but instead rely on the externals root makefile in Pd-extended SVN. Maintainers in need of a multi-platform helper makefile could consider https://github.com/pure-data/pd-lib-builder.
+1
mfgsdr IOhannes
On Thu, Oct 15, 2015 at 9:47 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-10-14 21:59, katja wrote:
So you've imported all Pd libraries from svn into git, preserving commit history... great initiative IOhannes! And it is hosted by IEM, couldn't be better.
What is your idea, should all maintainers immediately stop committing to SVN, and fork their libraries to git repositories?
i think the idea is to let the devs choose. if someone prefers to work with svn, so be it. if somebody else prefers gi, then they have now a history-preserving base repo to fork from.
Just to check if I understand the idea correctly: will that base repo be a frozen snapshot of Pd-extended commit history, not updated with possible future commits to SVN?
Katja
On 10/15/2015 10:40 PM, katja wrote:
On Thu, Oct 15, 2015 at 9:47 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-10-14 21:59, katja wrote:
So you've imported all Pd libraries from svn into git, preserving commit history... great initiative IOhannes! And it is hosted by IEM, couldn't be better.
What is your idea, should all maintainers immediately stop committing to SVN, and fork their libraries to git repositories?
i think the idea is to let the devs choose. if someone prefers to work with svn, so be it. if somebody else prefers gi, then they have now a history-preserving base repo to fork from.
Just to check if I understand the idea correctly: will that base repo be a frozen snapshot of Pd-extended commit history, not updated with possible future commits to SVN?
let's put it like this: i hope to keep future maintainance of the checkouts at a bare minimum.
there are still a few things left undone (see [1]), which need fixing (even without future SVN commit).
since there are not so many svn commits these days, i think it should be easy enough to replay any future commits on top of the git-repositories (so all SHAs stay the same).
gfmdsar IOhannes
Hi IOhannes,
Thanks for the hard work. From here, forking is probably trival.
Greetings,
Fred Jan
On 2015-10-14 04:15 PM, IOhannes m zmoelnig wrote:
On 2015-07-30 11:05, IOhannes m zmoelnig wrote:
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.
so i've done a first transition.
all the git-repositories can be found at
http://git.puredata.info/cgit/svn2git/
they are browsable and can be cloned directly from the webpage. however, these repos are meant as starting points, so we do not provide *any write* access. so once you forked, push to your own server (or gitlab, github, sourceforge, you name it) and let us no.
the process is documented (a little bit) on [1], but some parts of the migration had to be done manually (namely the selection of the paths to base the various libraries on; and the merging/re-rooting of repositories with independent branches).
so what is it?
an automated, history preserving, migration of the current svn directory into multiple git repositories, one for each library.
# why should i use this? if anybody who wants to start working on any of the pd-repo libraries uses the same git repo as root, it is trivial to merge those changes back together. so using those repositories as starting point, should make collaboration between independent devs a lot easier (compared to, when everybody does their own conversion, or just starts off wherever they think).
# what is included? i tried to capture as many libraries as possible (even those that had been removed from the svn a while ago). i tried to only include "libraries" (addons, plugins), regardless of whether they are "abstractions", "externals", "scripts" or "gui-plugins".
# what is not included? libraries that were only included via svn:externals (thus hosted on different servers). this is mostly, Gem, gridflow and grrrr. also some other libs that were not maintained on the svn but where only added/removed a few times (without adding any real history): these turned out to be too much of a hazzle for little value.
# externals vs abtractions i did not discriminate between the two. a few libraries were split on the two directories (e.g. abstractions/footils and externals/footils) and i have taken the liberty to re-combine them ("footils.git" contains both abstractions and externals)
# what is left to do? svn2git migration wise, probably not too much. however, i haven't really checked the resulting repositories (apart from generic sanity), so there might be bugs in the migration script itself.
have fun.
gfamsdr IOhannes
[1] https://github.com/umlaeute/pd-svn2git
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 14/10/15 22:15, IOhannes m zmoelnig wrote:
all the git-repositories can be found at http://git.puredata.info/cgit/svn2git/
Wow! Thank you.
Cheers,
Chris.
Thanks a lot Iohannes for this and for all of your efforts to maintain Pd related stuff.
cheers
antoine
-- do it yourself http://antoine.villeret.free.fr
2015-10-16 8:32 GMT+02:00 Chris McCormick chris@mccormick.cx:
On 14/10/15 22:15, IOhannes m zmoelnig wrote:
all the git-repositories can be found at http://git.puredata.info/cgit/svn2git/
Wow! Thank you.
Cheers,
Chris.
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On Wed, 2015-10-14 at 16:15 +0200, IOhannes m zmoelnig wrote:
On 2015-07-30 11:05, IOhannes m zmoelnig wrote:
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.
so i've done a first transition.
all the git-repositories can be found at
Great! Many thanks for all the effort.
they are browsable and can be cloned directly from the webpage. however, these repos are meant as starting points, so we do not provide *any write* access.
Ok, so what's the fuzz about non-secure connections when the repo's purpose is to _clone_ from it?
Roman
On 10/16/2015 02:41 PM, Roman Haefeli wrote:
Ok, so what's the fuzz about non-secure connections when the repo's purpose is to _clone_ from it?
because the repository could have been tempered with.
i *think* I have a proper solution to the problem, that is unrelated to https: if I gpg-sign the root commit of of each repository, then we would have a guarantee that the repository is the one that I uploaded.
gfmards IOhannes
On 10/16/2015 07:32 PM, IOhannes m zmölnig wrote:
On 10/16/2015 02:41 PM, Roman Haefeli wrote:
Ok, so what's the fuzz about non-secure connections when the repo's purpose is to _clone_ from it?
because the repository could have been tempered with.
i *think* I have a proper solution to the problem, that is unrelated to https: if I gpg-sign the root commit of of each repository, then we would have a guarantee that the repository is the one that I uploaded.
done.
all repos now have their root and head commits tagged as "svn2git-root" (resp. "svn2git-head"). if there are multiple roots resp. heads, they have an index attached (e.g. "svn2git-root.0")
these tags are signed by me (with the key that is attached to virtually all of my emails), and has a tag message that reads like:
"signed-tag: svn2git root of ${repo}"
with "${repo}" being replaced by the name of the actual repository. (in the case of multiple roots/headers, it will say something like "signed-tag: svn2git head.1 of ${repo}"
i consider this to be more safe than a mere transport encryption (as suggested by jonathan), as it guarantees the integrity of the repository itself (even if you get it by floppy disk).
mfsdr IOhannes
Hi Roman,If you do that over http then you don't have any way of knowing whether the data that you requested is the data that you get back. If you're going to be using this system, I'd suggest just hopping on the git user list and asking what is the best protocol to use by default for a publicly accessible repo of plugins in a free software community that isn't full of security experts.
If they suggest a setup like what IOhannes has implemented, then ignore everything I've written. If not, then you (or someone else who isn't me) might attempt revisiting this issue. -Jonathan
On Friday, October 16, 2015 8:42 AM, Roman Haefeli reduzent@gmail.com wrote:
On Wed, 2015-10-14 at 16:15 +0200, IOhannes m zmoelnig wrote:
On 2015-07-30 11:05, IOhannes m zmoelnig wrote:
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.
so i've done a first transition.
all the git-repositories can be found at
Great! Many thanks for all the effort.
they are browsable and can be cloned directly from the webpage. however, these repos are meant as starting points, so we do not provide *any write* access.
Ok, so what's the fuzz about non-secure connections when the repo's purpose is to _clone_ from it?
Roman _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On Fri, 2015-10-16 at 19:45 +0000, Jonathan Wilkes wrote:
Hi Roman, If you do that over http then you don't have any way of knowing whether the
data that you requested is the data that you get back.
Ah, I see. In my short-sighted notion of security I was only thinking about not revealing my credentials.
What IOhannes did - signing tags - tackles this very issue the single best way, if I understand the issue correctly.
Roman
Hi,
On 19/10/15 17:48, Roman Haefeli wrote:
On Fri, 2015-10-16 at 19:45 +0000, Jonathan Wilkes wrote:
If you do that over http then you don't have any way of knowing whether the data that you requested is the data that you get back.
With HTTPS you also don't know that.
HTTPS changes the trust/threat model but it is not magic. You still don't know if the data you requested is the data you get back (server compromise, SSL bugs, etc).
Of course I agree completely with Jonathan's point that HTTP requests should be made through an encrypted connection wherever possible.
What IOhannes did - signing tags - tackles this very issue the single best way, if I understand the issue correctly.
Another alternative is to obtain the SVN checkout and the git checkout of the particular external you want to build and compare them with e.g. recursive diff.
As always, the best possible thing is to review the code to ensure it does not contain any bugs or malicious code.
Cheers,
Chris.
On 07/07/2015 10:15 AM, Dan Wilcox wrote:
This is exactly what we were *nudging* for. It's not a movement against, just a growing process. The SVN has served it's purpose but now a more decentralized approach works since the tools and dev approach have changed.
I tried to respond to this, but I think the message didn't get through.
I now have a working instance of Gitlab up and running at the Oregon State Univ. Open Source Labs. I've been using it for a repo of the GUI port I'm working on.
If you don't know about OSUOSL, Google them. They host and assist a ton of big FLOSS projects. Because of them, we don't have to make a choice between the convenience of services like Sourceforge which we shouldn't be trusting (nor endorsing) and becoming full-time Unix administrators.
Just to give an example of their team-- I asked them about setting up an SSL cert for the subdomain they gave me. Before asking me some questions about how I intended to use the cert, they went ahead and set the whole process in motion. That way if it turned out to be a reasonable request-- and it was-- the cert would be ready to go by the end of the discussion. In other words, they did predictive branch support, which is impressive :)
My idea is that once the EFF's "Encrypt Everywhere" project is released, we'll be able to get a free subdomain cert for something like git.puredata.info or gitlab.puredata.info. Then we can just have that point at the Gitlab instance hosted by OSUOSL, and people can easily host their libs there instead of Sourceforge or Github. (Or migrate them or whatever.)
I'd like to make sure I've got sensible settings in Gitlab before I publish the URL. But if anyone wants to do that work for me, PM me and I'll send you the link.
-Jonathan
-
Antoine Villeret -
Chris McCormick -
Dan Wilcox -
Fred Jan Kraan -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jamie Bullock -
Jonathan Wilkes -
katja -
Roman Haefeli