[R] reliability of R-Forge?

[R P Herrold]

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