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

Stefan Theussl stefan.theussl at wu.ac.at
Tue Mar 30 14:17:13 CEST 2010 

On 03/28/2010 07:28 PM, Christophe Genolini wrote:
> 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.
As far as R-Forge is concerned, developers don't need to know how SSH 
works. Only the SVN client needs to be aware of it. One can always use 
passwords, private/public key authentication is not necessary here. 
Entering passwords multiple times is the only drawback of the keyless 
approach. I think question 5 is answered. Now, an attempt to answer the 
other questions:

> 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/.
I have to admit, there may be documentation for some part of the R-Forge 
system missing. But a) Section 3.2. of the R-Forge manual actually 
specifies very clearly when the cron job for updating SSH keys is run 
(namely once every full hour), b) the schedule at 
http://site.r-forge.r-project.org/ is usually up-to-date and c) I'm open 
to work with you together on a fancy status report similar to the 
bioconductor project.
>>>
>>>
>>>
>>> 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.
This was based on historic reasons. It seems indeed reasonable to drop 
this limitation. From now on, only the "Submit to CRAN button" is hidden 
from non-members of a project.

>>>
>>>
>>> 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).
This is because the 32bit system has been replaced and is not set up 
correctly yet. I hope we can fix this soon.
>>>
>>> Being able to access the r-forge server logs, similar to the
>>> Bioconductor status box, would help.
Agreed. Somebody needs to write code then ...
>>>
>>>
>>>
>>> 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.
See http://site.r-forge.r-project.org/. Packages are built in an, what 
you would call, "optimized" order. The aim is to built all packages in 
one cycle. But, there are far more constraints than just dependencies on 
specific version numbers of packages. One might also ask: What if 
package B is on CRAN *and* on R-Forge? Which one will it take? What if 
package C is on Bioconductor? Eventually, we will answer hopefully 
almost all of these questions. We are working on this at the moment.
>>>
>>>
>>>
>>> 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).
I don't think r-devel is the right list for asking questions about 
R-Forge. I always recommend using the forum.

Best,
Stefan
>>>
>>>
>>> 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
>>>>
>>
>

More information about the R-devel mailing list