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

From: Henrik Bengtsson <hb_at_stat.berkeley.edu>
Date: Sun, 28 Mar 2010 18:34:37 +0200


Hi,

first, r-forge.r-project.org 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 http://site.r-forge.r-project.org/, 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 http://site.r-forge.r-project.org/ 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 http://bioconductor.org/checkResults/2.6/bioc-LATEST/.

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 https://r-forge.r-project.org/forum/?group_id=34, 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 <d.scott_at_auckland.ac.nz> 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.
>>> http://sqldf.googlecode.com.  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.
>>>
>>
>> ______________________________________________
>> R-devel_at_r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> --
> _________________________________________________________________
> 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:  d.scott_at_auckland.ac.nz,  Fax: +64 9 373 7018
>
> Director of Consulting, Department of Statistics
>
> ______________________________________________
> R-devel_at_r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sun 28 Mar 2010 - 16:39:36 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 Mon 29 Mar 2010 - 10:21:17 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive