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

Sun Mar 28 19:28:57 CEST 2010

Wahou! I did not plan to start such a debate...
>> 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...
The problem is not how hard or easy it is, the problem is how time 
consuming it is.

I am pretty sur that I will manage to make it work. But when? I allready 
lose three hours Friday and two hour on saturday... That's definitly too 
much. Because I am not an engeneer in computing, I am a researcher. To 
make my research, I have to be expert in longitudinal data, in 
clustering, in anorexia, I have to speak english, I have to know R, and 
C, and package managing, and LaTeX, and gimp, and... and... and...
There is so many things to know... I can not be expert in all.

So I do not have time to (and I do not want to) explore all the ssh 
subtulties... Worse, I have a project, I manage to find some people that 
want to work on the projet (but that also have a lot of other staff to 
do), I do not want them to give up because it will take to much time for 
them to make ssh run.

Generalier, I think that anything should be done to make tools easy to 
use for non-expert, because more and more R user are occasional user. 
They are not experts, they don't want to become expert. They are just 
feed up to pay a lot of money for SPSS or Stata... But I guess this is 
another debate.

Christophe

> I wonder why nobody included the R-forge maintainer in this thread so 
> far. Let me add Stefan now.
>
> Best wishes,
> Uwe
>
>
>
> On 28.03.2010 18:34, Henrik Bengtsson wrote:
>> 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
>>>
>