From spencer.graves at structuremonitoring.com  Thu Aug 26 17:57:20 2010
From: spencer.graves at structuremonitoring.com (Spencer Graves)
Date: Thu, 26 Aug 2010 08:57:20 -0700
Subject: [Rd] reliability of R-Forge? (moved to R-Devel)
In-Reply-To: <alpine.LRH.1.00.1008261122110.8608@oebafba.bjyevire.pbz>
References: <AANLkTimaV9pQgY7rifD8ogsSiciTcvrZ3SsYCWZTYvRK@mail.gmail.com>	<1282808371.2302.69.camel@desktop.localdomain>
	<alpine.LRH.1.00.1008261122110.8608@oebafba.bjyevire.pbz>
Message-ID: <4C768EE0.6010302@structuremonitoring.com>

        I earlier moved a part of this thread to R-Devel, and got some 
replies there.


       At least one page on R-Forge says, "We are currently adapting the 
R-packages-plugin in order to work together with the new FusionForge 
infrastructure. Some services are thus not yet available."  I don't know 
if R-Forge is accepting new volunteers, but it looks like they could use 
help.  Unfortunately, I'm not in a position to volunteer.


       Best Wishes,
       Spencer Graves


On 8/26/2010 8:28 AM, R P Herrold wrote:
> On Thu, 26 Aug 2010, Gavin Simpson wrote:
>
>> On Thu, 2010-08-26 at 02:30 -0400, David Kane wrote:
>>> How reliable is R-Forge? http://r-forge.r-project.org/
>>>
>>> It is down now (for me). Reporting "R-Forge Could Not Connect to 
>>> Database: "
>
> late to chime in, so had tossed the first piece.  As this relates to 
> 'reliability of R-Forge' in the sense of possible process issues, 
> rather than availability of the archive, I wanted to 'tag into' this 
> thread
>
> I 'mirror' r-forge, so I have not seen this ...
>
> One thing I note, mirroring r-forge, and processing 'diffs' netween 
> successive days, is that the md5sums of some packages regularly change 
> without version number bumps.  From this morning's report in my email:
>
> Thu Aug 26 04:30:01 EDT 2010
>
> --- /tmp/rforge-pre.txt 2010-08-26 04:30:33.000000000 -0400
> +++ /tmp/rforge-post.txt        2010-08-26 04:38:03.000000000 -0400
> @@ -8,18 +8,18 @@
>  AquaEnv_1.0-1.tar.gz   615059a5369d1aba149e6142fedffdde
>  ArvoRe_0.1.6.tar.gz    c955ae7c64c4270740172ad2219060ff
>  BB_2010.7-1.tar.gz     4f85093ab24fac5c0b91539ec6efb8b7
> -BCE_2.0.tar.gz 5a3fe3ecabbe2b2e278f6a48fc19d18d
> -BIOMOD_1.1-5.tar.gz    d2f74f21bc8858844f8d71627fd8e687
> +BCE_2.0.tar.gz 65a968c586e729a1c1ca34a37f5c293a
> +BIOMOD_1.1-5.tar.gz    6929e5ad6a14709de7065286ec684942
>  ...
> -BTSPAS_2010.08.tar.gz  16b8f265846a512c329f0b52ba1924ab
> +BTSPAS_2010.08.tar.gz  809a96b11f1094e95b217af113abd0ac
>  ...
> -BayesR_0.1-1.tar.gz    72bd41c90845032eb9d15c4c6d086dec
> +BayesFactorPCL_0.5.tar.gz      173ab741c399309314eff240a4c3cd6f
> +BayesR_0.1-1.tar.gz    9560b511f1b955a60529599672d58fea
>  ...
> -BiplotGUI_0.0-6.tar.gz 594b3a275cde018eaa74e1ef974dd522
> +BiplotGUI_0.0-6.tar.gz 857a484fdba6cb97be4e42e38bb6d0fd
>  ...
> -IsoGene_1.0-18.tar.gz  679a5aecb7182474ed6a870fa52ca2e3
> +IsoGene_1.0-18.tar.gz  f37572957b2a9846a8d738ec88ac8690
>
> and so forth.  I've not taken the trime to understand why seemingly 
> new versions are appearing without version bumps yet.
>
> Is anyone aware of explanations, other than a release process that 
> does not require unique versioning of differing content? [it seems 
> pretty basic to me that a 'receiver' of new content could do the 
> checks I do, and decline to push conflicting md5sums over an 
> identically named prior candidate in archive]
>
> -- Russ herrold
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

-- 
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San Jos?, CA 95126
ph:  408-655-4567



[Rd] reliability of R-Forge? (moved to R-Devel)
Spencer Graves