R devel - Mar 2010 - Possible improvements/clarifications for R-forge (Was: Re: Using SVN + SSH on windows)

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
>

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

I agree that the R-Forge system is solid once you have it going but
its better if you are Linux based and less attractive if you are
Windows based. In particular if the two problems I cited before (use
of ssh and the delay) were addressed then together with the key
feature of automatic builds that it already has then it would be
usable for commits by Windows users.

What I don't agree with is that its easy on Windows if you know ssh.
I know ssh and have configured many Linux machines with it but it took
me two days to get R-Forge working on a Windows machine since trial
and error fiddling involves a delay for each attempt.  If you are
lucky it will work on your first attempt but if that one fails then
you are in for a potentially long series of trial and error attempts
potentially taking days.

Getting back to the original poster who may have been forgotten in all
this, alternatives are switching to Linux and using R-Forge with that
(if such a switch in platforms is feasible) or using googlecode
(that's the largest repository of R projects outside of CRAN with 237
R projects listed -- it uses https rather than ssh which eliminates
all the problems).

On Sun, Mar 28, 2010 at 12:34 PM, Henrik Bengtsson <hb at
stat.berkeley.edu> wrote:
> 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.