[Rcpp-devel] Please help in testing what will be Rcpp 1.0.5

[Dirk Eddelbuettel]

Hi all,

Below is an ascii version of what I blogged yesterday, proper URL links are
at   http://dirk.eddelbuettel.com/blog/2020/06/15#rcpp_1.0.5_testing

Help in testing, particular on unusual hardware or compiler choices, or
particularly old releases of OS, compiler, R, ... would be welcome. I am
quite confident the release will be fine on CRAN and standard systems.

But for use on less standard setups, the time to test is now. If you are a
user of Rcpp under such circumstance, please help now in testing and
reporting issues, if any are seen.

Thanks,  Dirk


  Mon, 15 Jun 2020

  Rcpp 1.0.5 in two+ weeks: Please help test

   rcpp logo

   With the current four-month release cycle, the next Rcpp release is due in
   July following the 1.0.4 release in March. Just prior to the 1.0.4 release
   I had asked this:

     It would be particularly beneficial if those with “unsual” build
     dependencies tested it as we would increase overall coverage beyond what
     I get from testing against 1800+ CRAN packages. BioConductor would also
     be welcome.

   but only on the rcpp-devel list, and only about a good week prior to the
   release.

   I remain rather disappointed and disillusioned about what happened after
   1.0.4 was released. Two PRs in that release were soon seen to have side
   effects on more ‘marginal’ test systems, precisely what added testing
   could have revealed. An additional issue arose from changes in R’s make
   system, which is harder to anticipate or test. Each and every infelicity
   was fixed within a day or so, and we always make candidate releases
   available—the current Rcpp as of this writing is 1.0.4.12 meaning twelve
   microreleases were made since 1.0.4. And those microreleases are always
   available for normal download and install.packages use via the Rcpp drat
   repository accessible to all. So it was truly troubling to see some,
   especially those with experience in setting up or running testing / ci
   platforms, pretend to be unable to access, install, and provide these for
   their own tests, or the tests of their users. It just doesn’t pass a basic
   logic test: it takes a single call to install.packages(), or, even more
   easily, a single assignment of an auxiliary repo. All told this was a
   rather sad experience.

   So let’s try to not repeat this. If you, or maybe users of a build or ci
   system you maintain, rely on Rcpp, and especially if you do so on systems
   outside the standard CRAN grid of three OSs and the triplet of “previous,
   current, next” releases of R, then please help by testing. I maitain these
   release as a volunteer, unpaid at that, and I simply cannot expand to more
   systesm. We take reverse dependency check seriously (and I just run two
   taking about a day each) but if you insist on building on stranger
   hardware or much older releases it will be up to you to ensure Rcpp
   passes. We prep for CRAN, and try our best to pass at CRAN. For nearly a
   dozen years.

   To install the current microrelease from the Rcpp drat repository, just do

 install.packages("Rcpp", repos="https://rcppcore.github.io/drat")

   That is all there is to it. You could even add the Rcpp drat repository to
   your repository list.

   Rcpp has become successful because so many people help with suggestions,
   documentation, and code. It is used by (as of today) 1958 CRAN packages,
   205 BioConductor packages, and downloaded around a million times per
   month. So if you can, please help now with some more testing.

   If you like this or other open-source work I do, you can now sponsor me at
   GitHub. For the first year, GitHub will match your contributions.

   This post by Dirk Eddelbuettel originated on his Thinking inside the box
   blog. Please report excessive re-aggregation in third-party for-profit
   settings.

                                                  /code/rcpp | permanent link



-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org