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
> 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
