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

Sun Mar 28 18:34:37 CEST 2010

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
>