To what extend could the single package builder be used for such a feature? This would not address Michael's point, but it is a way to get access to all archs using existing software infrastructure.
Laurent On 2 June 2015 13:18, Michael Lawrence wrote: > Maybe the motion towards github and the work Gabor C has been doing on > Travis integration might help with this? > > Note that a proper check should test all reverse dependencies of your > package, and that would get expensive for some of the more core > packages... so that might need to be deferred to the regular > repository-level build process. > > > On Tue, Jun 2, 2015 at 2:48 AM, Sean Davis <[email protected]> wrote: >> On Tue, Jun 2, 2015 at 5:32 AM, Vincent Carey <[email protected]> >> wrote: >> >>> I agree that this would be nice; not sure how feasible. Could a specific >>> approach with containers provide a solution? >>> >> >> Unfortunately, containers are linux microkernels, so Windows and MacOS are >> basically out. >> >> >>> On Mon, Jun 1, 2015 at 11:09 PM, Kasper Daniel Hansen < >>> [email protected]> wrote: >>> >>> > For a substantial number of issues with R CMD check, it is easy to >>> > reproduce the errors/warnings/notes on my own system; simply update all >>> > packages and run the test. >>> > >>> > For a small number of errors I have sometimes (over the years) had >>> problems >>> > reproducing them, perhaps because they are platform specific or because >>> of >>> > other issues. >>> > >>> > In those cases, especially for packages which I work on infrequently, the >>> > current submission / check introduces a long delay and - more >>> importantly - >>> > substantial mental overhead for me. This is because I submit a fix and >>> > then I usually have to wait 36-48h to see the result of R CMD check. >>> > >>> > It would be great if we could get access to running R CMD check on all >>> > three platforms by demand, with a results page which is semi-private (to >>> > not confuse the package with a fix with the official devel version). I >>> > realize this could be misused or introduce a large computational overhead >>> > on the project. Perhaps only make this available for packages accepted >>> > into the project. But it would be nice. For example, I have been >>> hunting >>> > a bug in minfi for like 10 days now, and the fact that I need to wait 48h >>> > to get the result of a fix, really makes this painful. >>> > >>> > Best, >>> > Kasper >>> > >>> > [[alternative HTML version deleted]] >>> > >>> > _______________________________________________ >>> > [email protected] mailing list >>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> > >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> [email protected] mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> [email protected] mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > _______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Laurent Gatto | @lgatt0 http://cpu.sysbiol.cam.ac.uk/ _______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
