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

From: Christophe Genolini <cgenolin_at_u-paris10.fr>
Date: Sun, 28 Mar 2010 19:28:57 +0200

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
>>>
>



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sun 28 Mar 2010 - 17:35:48 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 Wed 31 Mar 2010 - 09:01:19 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