Forum OpenACS Development: Using Sourceforge Subversion for OpenACS

1: Using Sourceforge Subversion for OpenACS

Posted by Malte Sussdorff on 04/29/07 10:56 AM

In the discussion about how to increase awareness for OpenACS and the aim to attract developers one of the recommendations of the participants has been to move OpenACS CVS directory to SourceForge SVN and open a project page there.

According to the experiences with ]po[ this will result in a high exposure of the toolkit to outsiders who might not have heard about OpenACS before, due to the high activity as a result of our active commits.

Additionally we could offer the releases for download there (in addition to openacs.org). And we would not have to deal with hosting the repository.

My understanding was to not use their forums or bug tracker, as the ones we have on openacs.org are more sophisticated and served us well (apart from "eat your own dogfood").

I personally see a lot of value in this, especially as we want to move to subversion anyway. But before I write a TIP about this, I would like to consolidate opinions from more people in the community than the nearly 20 who where in favor of this movement in Vienna.

One note though: ]po[ is using sourceforge for forums and bugtracker and NOT for the repository of code (before anyone jumps on this fact). This is most likely due to their use of proprietary code for which they need a version system anyway.

Risks I see though:

* People might use the sourceforge bug tracker and forums, especially newbies who do not know about the community. For them we would probably have to put up announcements to check out our bugtracker and forum.
* Additional risk might be that sourceforge SVN is down. But as this is going to be an issue for more projects than just us, we should not have to worry about that too much as it is in their interest to fix it. And if we don't trust them I am sure we can keep a backup somewhere 😊.

2: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Daniël Mantione on 04/29/07 03:37 PM

Well, with the Free Pascal project I'm part of we have had this discussion some time ago too. SVN is a rather essential service as it contains the entire history of the project.

Outsourcing it means a third party gets a certain control over your history. This is not a problem now, but you can never exclude VA Software becomes a SCO or so.

Another issue to consider is Sourceforge means your work will reside on American servers. For OpenACS this might be different issue than for Free Pascal, but we feel that on our own server in Belgium we are much safer against mad American laws like software patents.

3: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Dave Bauer on 04/29/07 06:44 PM

From my extremely limited personal experience, sourceforge is unavailable quite often. I don't ever recall the OpenACS CVS server being unavilable (and if it is, I am one of the people responsible for it.) Does anyone have more experience for using sourceforge for a code repository? Maybe there is a way to mirror commits from an OpenACS SVN repository to sourceforge. That would create a backup of the code, and increase visibility and allow the community to control the official repository.

Currently the openacs.org web site and CVS already resides in the US.

Originally the OpenACS 3 project was in Sourceforge. I don't remember why it was moved. Perhaps someone does remember.

4: Re: Using Sourceforge Subversion for OpenACS (response to 3)

Posted by Gustaf Neumann on 04/30/07 11:53 AM

dave said: From my extremely limited personal experience, sourceforge is unavailable quite often.

I share this experience, although it became better lately. What's even more disturbing for me is that the time gap between a commit and the availability of a commit can be quite large (from hours to days). This adds another dimension for discussions about which version is installed, and requires either polling for a new version, or sometimes sending versions via email. There are alternatives to sourcefore not having this problem, but still, for visibility sourceforge is certainly better. Mirroring seems a good compromise, although i have no experience with this. Note, that SF is not only a code repository, but also a place for discussions about the code. Have two such places is no good idea from my experience.

5: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Tom Jackson on 04/30/07 05:54 PM

Isn't one of the prerequisite skills for OpenACS developers the ability to setup a code repository for dev, stage and live? I doubt you will find many good developers who just want to write code and don't need to deploy and customize using the multi-server model; that is, your developers are your users. It is a high bar for entry, but the code is pretty complex. Maybe that is why ArsDigita had boot camps, but they were actually trying to drum up employees during boom times.

I like SVN, but I have not looked into how you can maintain CVS and SVN at the same time, or why you would do that. But if Gustaf is correct about a time delay in commits becoming visible, this is a disaster. Maybe the delay is only for non-developers? Otherwise the whole concept of the repository is lost. I have experienced downtimes with SourceForge, but I don't maintain code there, so I don't know how much it would affect a developer, but downloads via CVS seem slow. Also, AOLserver code is hosted there and you get split discussions with the AOLserver mailing list, and nearly unreadable messages from SourceForge on bugs.

6: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Dave Bauer on 04/30/07 08:29 PM

Lets step back and ask "why" we would want to switch. What are the perceived benefits.

So far I have this from the thread:

1) increase exposure, OpenACS has daily commits during active development, so it would get listed as an active project on sourceforge. Question: how many people can we attract this way? Would there be another way to get this type of publicity? Could we mirror our repsitory to sourceforge with a script?

2) Offer downloads frm there. Not much benefit there, we have a download package and seem to have a reasonable system for managing the release process. Not a big benefit there.

3) We would not have to host the code repository. We have a donated machine that is working quite well, and volunteers to maintain it so not alot of benefit here.

Downsides to sourceforge

1) slow, or unavailable repository.

Is there anything I am missing? What was discussed at the meeting as the reasons for switching.

8: Re: Using Sourceforge Subversion for OpenACS (response to 6)

Posted by Malte Sussdorff on 05/01/07 10:50 AM

Dave, you pretty much summed it up. It was a very brief discussion with the motion to move the repository to sourceforge for greater exposure. This includes having them track the number of downloads to see how out toolkit fairs in comparison.

What I personally draw from the feedback is, apart from the idea of mirroring the code, we should not move it over to sourceforge, so I won't TIP it. Thanks for the feedback guys.

That being said, there are other suggestions from that meeting which will be posted about soon which I hope should help us with regards to exposure to new developers.

9: Re: Using Sourceforge Subversion for OpenACS (response to 6)

Posted by Daniël Mantione on 05/02/07 09:56 PM

The expose andvantage is basically a form of seach engine optimization, the SourceForge search engine ranks you higher if you have a high activity score.

While we do everything ourselves, placing downloads on Sourceforge too, already puts us in the top 300 of high activity.

Still, I think this is a very poor way of exposure. Things that expose Free Pascal are for example:

* Benchmarks, being no 1 helps a lot :) : http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=1&xloc=1&binarytrees=1&chameneos=1&message=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=1&nbody=1&nsieve=1&nsievebits=1&partialsums=1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=1&sumcol=1
* Contests: http://www.pascalgamedevelopment.com/competitions.php?p=details&c=3
* Being used by commercial companies, example: http://www.morfik.com
* Evangelism by users, example: http://ik.homelinux.org/index.rhtml/other/lectures/fpc_about

All of these things share one thing: They happen outside freepascal.org and are initiated by the community, not the developers.

For OpenACS, it is the best web toolkit, it has amazingly talented developers, and has commercial backing. Going to Sourceforge just to be found in their search engine seems a sign of weakness to me. The fundament is to have a strong community, and this is what OpenACS needs to work on.

7: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Dave Bauer on 04/30/07 08:32 PM

Another note, there is some interest in moving the OpenACS repsoitory to Subversion anyway, before the disucssion of sourceforge was begun. So switching to SVN is doable without moving the code repository, and it should be quite simple to mirror an OpenACS SVN repository to another SVN repository.

10: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by merv colton on 05/03/07 12:11 PM

The reasons to move to SourceForge are not purely techncial. While there is a strong community here, it's not as large as it could be, and by being on SourceForge we would get more exposure and that would grow the community.

We may well have the best software in the world, but it's also one of the best kept secrets. Using Sourceforge would help get the message out.

Merv.

11: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Dave Bauer on 05/03/07 01:30 PM

Merv,

I think Daniel is right. Just having a listing on sourceforge doesn't help the community as much as the community itself, promiting the toolkit. Writing about how you use OpenACS, and showing with actual web sites built on OpenACS seems like a much more effective way to promte the toolkit.

At one time, most folks found OpenACS by reading http://philip.greenspun.com/panda/ which is basically a bunch of web pages describing the toolkit and its philopshy in detail. Of course, OpenACS has moved on from there. So that kind of information, whether its in a good, or distributed on a network of folks blogging about OpenACS seems like an effective way to teach people about OpenACS.

12: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Nima Mazloumi on 05/03/07 01:37 PM

Sourceforge is the place to look for active projects which OpenACS is. Thus it will have a high rank and this by itself is going to promote the project. Franks project is a perfect proof. Other steps might be required as well. But this is surely one of the puzzle. I think instead of discussing if we should or not we should find the most convenient way.

13: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Dave Bauer on 05/03/07 01:54 PM

Thanks Nima,

I agree with you. I don't care if OpenACS is listed on sourceforge, I just object to using it for our main repository.

I suggest a volunteer

1) convert OpenACS repository to SVN using cvs2svn. If you use the latest version it works, except for a few invalid history entries which can be edited out of the repository.

2) figure out how to synch commits to sourceforge. Perhaps a cron job that runs once a day would work well without causing a script to contact SF after every commit. (This also helps if SF is down, the cron job might fail, but individual commits to the OpenACS repository will be fine.)

14: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Jon Griffin on 05/03/07 05:18 PM

Is there any way to run subversion on AOLServer? I know that it is Apache centric.
According to the book, svnserve can be used over ssh. Is that what the plan for locally hosted repository?

I hate sourceforge and really hope that development doesn't get moved over there.

15: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Dave Bauer on 05/03/07 05:42 PM

Jon,

We should probably use apache. Then we can control access to the repository without giving shell accounts to all the committers.

16: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Daniël Mantione on 05/03/07 06:12 PM

SVN requires WebDAV. Apache will be the easiest, but WebDAV with AOLserver doesn't seem impossible to me.

17: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Don Baccus on 05/03/07 10:46 PM

In the discussion about how to increase awareness for OpenACS and the aim to attract developers one of the recommendations of the participants has been to move OpenACS CVS directory to SourceForge SVN and open a project page there.

This is inaccurate. Frank proposed we move to Sourceforge. There were objections raised. The alternative - we link from sourceforge - was offered and no one seemed to have a problem with that.

About then I got this "how fucking stupid are we going to be" feeling and walked out of the meeting, perhaps after I left people changed their mind and decided it was a great idea.

Sourceforge gives second-rate service for second-rate projects that can't afford their own servers and bandwidth. It's unreliable, you're dependent on the goodwill of a company, etc etc. It's a great service for those who can't afford to host their own project. We can and do. We started on SourceForge because OpenACS 3 began as a personal project of Ben Adida, me and Roberto Mello, and at the time none of us had a personal server with bandwidth available for hosting. Reaching the point where we could self-host our repository with great bandwidth and a nice server was a milestone for our project. Suggesting we toss it aside and move backwards is ludicrous.

Merv's comment isn't quite strong enough. There's NO technical reason to move. It's ALL about a perception of a "marketing benefit". From a technical point of view it's right up there with rewriting the toolkit in .NET and SQL Server ...

Dave's comment about subversion isn't quite right, either. We've formally decided to move to subversion, took that decision a few months ago in the OCT. The only thing that's stopped us was that Lee's trial run of the cvs to svn conversion tool choked on some of our repository. So the move has been put on hold until someone has time to figure that out and fix it (I think we've talked about that happening in early summer we hope???).

So please don't talk about Sourceforge and SVN as though somehow moving to Sourceforge will lead to a decision to switch to SVN.

Moving our repository to Sourceforge is pretty much an "over my dead body" issue, I'm afraid. The proposal came from Frank Bergman, who wasn't nominated for a second OCT term because he never attended a single meeting. Not exactly a hardcore member of this community.

Malte, if you're serious about this, please TIP it so I can vote "no" ASAP please.

19: Re: Using Sourceforge Subversion for OpenACS (response to 17)

Posted by Malte Sussdorff on 05/04/07 12:07 AM

Don, as you aptly observed, you walked out on the meeting. There was talk, there was discussion and there was a show of hands. That's what promted me to make the suggestion public. Had you read further before starting your comment you would have read my comment of *NOT* tipping this after recieving the feedback from the community. Anyone else can, but I'm not convinced moving over there is a good decision, anymore.

On the other hand, I do not think that singleing out Frank in the way you did is appropriate. It was his suggestion, yes, but it found approval by more people, including me, during that meeting. But that group did not constitute the whole community and the whole wisdom of the community. This is why I brought this up so we had the discussion in public.

Additionally it has never been my intention to link moving to SVN to moving to sourceforge in a manner where it means: "We need to move to sourceforge so we can move to SVN". I'm slowly doubting my english communication skills here in the forums 😊.

As you aptly suggested, we need someone who has the resources to see the move to SVN happen. And while he is at it, he might be wiling to take a look at getting a copy of the SVN synchronized to sourcefore. Or not, as Danielle mentioned, it might not matter that much. Yet I am *not* convinced we should be held up by the fact that we encounter errors with moving the history, if we are serious about moving to SVN, but that is an utterly different issue.

Again, there have been other suggestions on how to improve the visibilty of the community and I just hope that between Nima (who took notes) and Caroline (who chaired the meeting) they will come up again, otherwise I will have to continue posting (with all the repercussions this might entail (joking!!)). The topic of moving the repository over to sourceforge for me is dead, unless the resource providing SVN for OpenACS is willing to setup a sync server to sourceforge.

18: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Daniël Mantione on 05/03/07 11:14 PM

An example:

www.oacsrocks.org is a wonderfull example of OpenACS promotion outside openacs.org. The kind of promotion you need, because you can only show people the power of OpenACS by letting people use and try it.

But, why is digging through the forums the only way the potential users can find this piece of gold???

If users start initiatives, link it, post news on openacs.org etc. OpenACS has it all, it needs to use it :)

20: Re: Using Sourceforge Subversion for OpenACS (response to 18)

Posted by Malte Sussdorff on 05/04/07 12:09 AM

Amen to that and all your other suggestions. We should revive them in a more prominent space and out of the context of this thread, as the topic is misleading and your suggestions would probably face the same fate as the other pieces of gold burried in the forums.

21: Re: Using Sourceforge Subversion for OpenACS (response to 1)

Posted by Jade Rubick on 05/09/07 07:05 AM

I'm surprised nobody has suggested hosting it on Google. Their service has been reliable (at least so far), and then we wouldn't have to worry about hosting Subversion.