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

Sun Mar 28 18:49:33 CEST 2010

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