Re: [Rd] Possible improvements/clarifications for R-forge (Was: Re: Using SVN + SSH on windows)

From: Uwe Ligges <>
Date: Sun, 28 Mar 2010 18:49:33 +0200

I wonder why nobody included the R-forge maintainer in this thread so far. Let me add Stefan now.

Best wishes,

On 28.03.2010 18:34, Henrik Bengtsson wrote:
> Hi,
> first, is filling a need and provides a great
> service to the community. Please read this thread as sincere feedback
> for making it even better, not as a complaint. I fully understand
> that r-forge is ran by limited resources and on a volunteer basis.
> I'll list some points about r-forge that I think could be
> improved/clarified. Not expecting anything, just sharing my
> experience.
> 1. Part of the R-forge services runs on a schedule, e.g. building and
> checking packages. As a user you do not really know when this
> happens.
> Some of this is documented at, but
> not everything, e.g. as seen in another message on r-devel, the cron
> job for updating SSH keys is not specified. Moreover, all static
> documentation tends to become outdated. In other words, as a user I
> am not certain that is up to date.
> Providing some kind of online log of what the r-forge servers are
> doing would help the user to plan, troubleshoot etc. Right now there
> are too many degrees of freedom to figure out what and when things
> happens. The Bioconductor project provides a small log summary/status
> with timestamps of the last run, cf. small box at the top of
> 2. It is not possible to check the R CMD build/check log files for
> other people's packages.
> The log files are considered private to the project members. This
> means that I cannot troubleshoot other packages part of projects that
> I am not a member. This limits my chances to troubleshoot problems I
> have when my package depends on an external package. It also limits
> my chances to contribute with troubleshooting/bug reports for other
> packages. This is one of the features that makes the Bioconductor
> repository a success. Making these log files public would improve lots
> of things.
> 3. For some OSes, the log files for the build and check of packages are missing.
> For instance, none of my packages has log files for Linux x86_32, e.g.
> "Logfile for R.batch not available.". It is not clear if this is
> because I made something wrong, or this is the flavor of the day, or a
> permanent error. (I looks permanent for "Linux x86_32", but not sure
> about the others).
> Being able to access the r-forge server logs, similar to the
> Bioconductor status box, would help.
> 4. It is not clear how dependencies are dealt with in the build/check process.
> If I have r-forge packages A v1.0.0, B v1.0.0, and C v1.0.0, and
> package A depends on B (>= 1.0.0) and package B depends on C (>=
> 1.0.0), when are these packages built? Are they built in
> lexicographic order or in some optimized order? For instance, if I
> bump the versions of the packages and the dependencies to B (>= 1.1.0)
> and C (>= 1.1.0), when will package A be build and available? If
> there is a lexicographic build/cron cycle, will it take three cycles?
> Will A and B fail in the first cycle when only C is build. Then in
> the 2nd cycle, will A fail and B and C build, and in the 3rd cycle
> also A will build?
> Again/thus, when my package A is not available, is that because I did
> something wrong, the cron job had hiccups is delayed, or something
> else. Seeing the full server logs or other status reports would help.
> 5. No https access - only svn+ssh access with private/public keys
> The svn+ssh protocol for SVN commits is a show stopper for people who
> never used SVN or ssh authentication keys before. It is easy for
> someone who knows how it should work, but quite hard to troubleshoot
> if you don't know what to expect. It is hard to help someone get
> started without being next to them on their computer. This makes it
> hard to convince people who "don't really" care to start using SVN and
> r-forge (which would improve overall quality in the long run).
> Supporting SVN commits over https would lower this threshold.
> 6. The r-forge forum is not really active.
> There is a forum at,
> but it is not very active and several questions are unanswered. In
> order catch momentum, I think posting r-forge questions to r-devel
> would work better and reach more people that can help out. (This is
> why this is posted to r-devel).
> Cheers,
> Henrik
> On Sun, Mar 28, 2010 at 5:45 AM, David Scott<> wrote:
>> Uwe Ligges wrote:
>>> It is really not hard to set it up. I am using a vanilla ssh (rather than
>>> putty) and that works fine all the time...

>>> Uwe Ligges
>> Ditto here. I am using ssh non commercial version with tortoise on Vista,
>> and I don't recall any problems setting it up. R-forge works perfectly fine
>> with windows and tortoise in my experience.
>> Is your putty/ssh working? Can you access other machines with it? I do
>> recall ssh can be a bit fussy.
>> David Scott
>>> On 27.03.2010 18:31, Gabor Grothendieck wrote:
>>>> s getting commits to R-Forge to work from
>>>> Windows. The entire system is really geared to UNIX. It took me a
>>>> couple of days of trial and error (since you have to wait 20 minutes
>>>> for each try) before I got it working. Although I did get it to work,
>>>> I ultimately decided to host all my packages on googlecode.
>>>> googlecode is extremely easy to use from Windows and does not require
>>>> any public/private key, pageant, etc. e.g.
>>>> If you already have TortoiseSVN and know
>>>> how to use it then you can probably set up a googlecode site in
>>>> literally 5 minutes.
>>>> One other possibility. I think there is a way to host your project on
>>>> googlecode but still have it mirrored on R-forge so from your users'
>>>> viewpoint its the same as if it were on R-Forge but you can use the
>>>> simpler googlecode site. In that case you might not need to set up
>>>> commits on R-Forge since you would do all your commits through
>>>> googlecode (depending on how it works) but I have not seen good
>>>> documentation on how to do this.
>>> ______________________________________________
>>> mailing list
>> --
>> _________________________________________________________________
>> David Scott Department of Statistics
>> The University of Auckland, PB 92019
>> Auckland 1142, NEW ZEALAND
>> Phone: +64 9 923 5055, or +64 9 373 7599 ext 85055
>> Email:, Fax: +64 9 373 7018
>> Director of Consulting, Department of Statistics
>> ______________________________________________
>> mailing list
>> mailing list Received on Sun 28 Mar 2010 - 16:53:01 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sun 28 Mar 2010 - 18:01:17 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive