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.sc...@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@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.sc...@auckland.ac.nz, Fax: +64 9 373 7018
Director of Consulting, Department of Statistics
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
