Okay, thanks. And thank you all for putting in your time and effort!
Christopher Njuguna cell: +254 717 916 343 cell: +254 739 956 510 gchat: chris.njuguna skype: christopher.njuguna twitter: @chrisnjuguna On Mon, May 21, 2018 at 7:20 PM, Uwe Ligges <lig...@statistik.tu-dortmund.de > wrote: > Well, on incoming, we only check on two systems and the Windows timings > will be reported in the message you receive, you can also see them when > using the winbuilder service. > > For some of the other OS/ R flavors, you can see them after they are > published on CRAN on the check summary pagesa on CRAN, e.g. for > Rnightlights: > > https://cran.r-project.org/web/checks/check_results_Rnightlights.html > > Noet that Windows typically takes much longer as some parts of the checks > are performed for 32-bit and 64-bit. > > Best, > Uwe Ligges > > > On 21.05.2018 18:16, Chris Njuguna wrote: > >> Thanks Uwe, >> >> I think the timeouts are helpful also in encouraging better coding >> practices. I will try to limit my tests as described by Dirk especially >> since I am planning to increase my code test coverage. Is it possible to >> get the test timing breakdowns for each flavor? >> >> Christopher Njuguna >> cell: +254 717 916 343 >> cell: +254 739 956 510 >> gchat: chris.njuguna >> skype: christopher.njuguna >> twitter: @chrisnjuguna >> >> On Mon, May 21, 2018 at 6:46 PM, Uwe Ligges < >> lig...@statistik.tu-dortmund.de <mailto:lig...@statistik.tu-dortmund.de>> >> wrote: >> >> In addition to what Dirk said, I just added this experimental test >> for CRAN incoming checks few days ago and it should not reject but >> lead to manual inspection, this will be fixed on CRAN side shortly. >> >> Nevertheless: The idea is that we have timeouts for checking a >> package and we want to be alerted of future timeout problems in >> advance when a package is submitted. >> >> Best, >> Uwe Ligges >> >> >> >> On 21.05.2018 14:06, Dirk Eddelbuettel wrote: >> >> >> I can't speak to the recent increase on Windows. It may be load; >> it may be >> related to R 3.5.0 --- but I'd even whittle things down from 5+ >> minutes. At >> one point in the past we were told to aim for 1 minute, give or >> take. >> >> So e.g. Rcpp has been using a scheme for _many_ years where I >> take a cue from >> the DESCRIPTION file. The rule I like (for my packages) is that >> versions like >> >> 1.2.3.1 >> >> are "development" so I do a full test. Whereas versions like >> >> 1.2.4 >> >> are "release" -- so when I only see three components, I set a >> variable. And >> the unit tests file can then use that variable to skip tests. >> This gives me >> fine-grained control: lighter-weight tests can still run in both >> cases. Hence >> shorter test time for release uploads at CRAN; yet I still get >> full tests at >> win-builder when I send a development version. >> >> Dirk >> >> >> [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel