I haven't used rforge, but I will look check out the scripts. The reason it would be a six-pack of work is that there are generic build systems that handle most of this work. What they don't do is act as a repository, so rforge could remain that while separating out the build process.
On Sep 16, 2013, at 4:58 AM, Matthew Dowle <mdo...@mdowle.plus.com> wrote: > On Sep 16, 2013, at 01:46 PM, Brian Rowe wrote: > >> That reminds me: I once made a suggestion on how to automate some of the CRAN >> deployment process, but it was shot down as not being useful to them. I do >> recall a quote that was along the lines of "as long as you don't need help, >> do whatever you want", so one thought is to just set up a build server that >> does the building across the three versions of R, checks dependencies, >> rebuilds >> when release, patch, or devel are updated, etc. This would ease the burden on >> package maintainers and would just happen to make the CRAN folks' lives >> easier >> by catching a lot of bad builds. A proof of concept on AWS connecting to >> github >> or rforge could probably be finished on a six-pack. Speak up if anyone thinks >> this would be useful. > > Yes useful. But that includes a package build system (which is what breaks on > R-Forge). If you could do that on a six-pack then could you fix R-Forge on a > three-pack first please? The R-Forge build system is itself an open source > package on R-Forge. Anyone can look at it, understand it and change it to be > more stable. That build system is here : > > https://r-forge.r-project.org/R/?group_id=34 > > (I only know this because Stefan told me once. So I suspect others don't know > either, or it hasn't sunk in that we're pushing on an open door.) > > Matthew > > ______________________________________________ > 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