plan next release

[bbolker]

Opening this to start planning because it always takes a long time (and because we may get a notice from CRAN any day now [once they return from their vacation] about some of the outstanding CRAN-check issues (which are already fixed in master) ...

• new version number: 1.1.9 or 1.2.0 ?
• revdep checks (as always)
• make sure NEWS is up to date (ditto)
• resolve CRAN check issues (no_remap, missing links; MacOS LaTeX errors don't seem to be our fault)
• merge easy PRs (make sure to REPORT corrdisp, sddisp (GH #1058) #1083, Up2date mapped disp #1077, add prediction of latent variables. #1062)
• ?? less-baked/less straightforward PRs?? (propto covstruc #1068, Save smooth info #1075, Test implementation of glmmTMB leverage function #1065, Extend RE form #1067)
• any other low-hanging fruit and/or critical issues ?

[jamesdalg]

I'm excited by the leverage functions. Hopefully they come out soon. Thanks again.

[strengejacke]

I think #1006 is relatively easy (or already done?). Nice to have would be the second point in #1015.

[mebrooks]

CRAN gave us a deadline for the next release 2024-09-20. They said
"Please see the problems shown on
https://cran.r-project.org/web/checks/check_results_glmmTMB.html.

Specifically, please see the noRemap additional issue.

Compilation fails when using R_CXX_NO_REMAP=true, which compiles C++
code with R_NO_REMAP defined. See chapter "The R API: entry points for
C code" in "Writing R Extensions" for more information.

It is planned that R_CXX_NO_REMAP=true will become the default in due
course, ideally already for R 4.5.0, which in particular makes it
necesssary that all CRAN packages with many strong reverse dependencies
compile/install ok with the new default.

Your package is among the ones with many strong reverse dependencies.
We would thus really appreciate if you could provide a new version of
your package as soon as possible which checks ok with
R_CXX_NO_REMAP=true.

You can verify that your package checks ok with R_CXX_NO_REMAP=true
via R CMD check --as-cran using a current version of R-devel."

[bbolker]

FWIW the R_NO_REMAP stuff was dealt with a long time ago. (From the fix_noremap branch, merged in 4879852.) We just have to decide what we want to squeeze in to the release.

[bbolker]

Our deadline is now 12 days away ... it would be nice to add the experimental leverage stuff from #1065, but at present we can't do it without inducing a dependency on RTMB ... it also fails checks due to use of an unexported function from TMB, and segfaults on GitHub actions (!!)

[bbolker]

Running on win-builder gives a NOTE. This r-pkg-devel post says it is a false positive "now fixed" but maybe it didn't get fixed everywhere? (I think we should mention it in our submission)

I bumped the version and added all the NEWS updates I could find by looking through git logs. As far as I know it's ready to go after reverse dependency checks, although we might want to merge the last 5 unmerged PRs? (#1068, #1075, #1087, #1094, #1097) even though some of them are only partly baked?

• checking DESCRIPTION meta-information ... NOTE
  Author field differs from that derived from Authors@R
  Author: 'Mollie Brooks [aut, cre] (ORCID: https://orcid.org/0000-0001-6963-8326), Ben Bolker [aut] (ORCID: https://orcid.org/0000-0002-2127-0443), Kasper Kristensen [aut], Martin Maechler [aut] (ORCID: https://orcid.org/0000-0002-8685-9910), Arni Magnusson [aut] (ORCID: https://orcid.org/0000-0003-2769-6741), Maeve McGillycuddy [ctb], Hans Skaug [aut] (ORCID: https://orcid.org/0000-0003-4235-2592), Anders Nielsen [aut] (ORCID: https://orcid.org/0000-0001-9683-9262), Casper Berg [aut] (ORCID: https://orcid.org/0000-0002-3812-5269), Koen van Bentham [aut], Nafis Sadat [ctb] (ORCID: https://orcid.org/0000-0001-5715-616X), Daniel Lüdecke [ctb] (ORCID: https://orcid.org/0000-0002-8895-3206), Russ Lenth [ctb], Joseph O'Brien [ctb] (ORCID: https://orcid.org/0000-0001-9851-5077), Charles J. Geyer [ctb], Mikael Jagan [ctb] (ORCID: https://orcid.org/0000-0002-3542-2938), Brenton Wiernik [ctb] (ORCID: https://orcid.org/0000-0001-9560-6336), Daniel B. Stouffer [ctb] (ORCID: https://orcid.org/0000-0001-9436-9674)'
  Authors@R: 'Mollie Brooks [aut, cre] (https://orcid.org/0000-0001-6963-8326), Ben Bolker [aut] (https://orcid.org/0000-0002-2127-0443), Kasper Kristensen [aut], Martin Maechler [aut] (https://orcid.org/0000-0002-8685-9910), Arni Magnusson [aut] (https://orcid.org/0000-0003-2769-6741), Maeve McGillycuddy [ctb], Hans Skaug [aut] (https://orcid.org/0000-0003-4235-2592), Anders Nielsen [aut] (https://orcid.org/0000-0001-9683-9262), Casper Berg [aut] (https://orcid.org/0000-0002-3812-5269), Koen van Bentham [aut], Nafis Sadat [ctb] (https://orcid.org/0000-0001-5715-616X), Daniel Lüdecke [ctb] (https://orcid.org/0000-0002-8895-3206), Russ Lenth [ctb], Joseph O'Brien [ctb] (https://orcid.org/0000-0001-9851-5077), Charles J. Geyer [ctb], Mikael Jagan [ctb] (https://orcid.org/0000-0002-3542-2938), Brenton Wiernik [ctb] (https://orcid.org/0000-0001-9560-6336), Daniel B. Stouffer [ctb] (https://orcid.org/0000-0001-9436-9674)'

[mebrooks]

I have all day tomorrow to focus on this.

[mebrooks]

I get one warning when I check as CRAN on my computer (below). I'm also installing everything on DTU's cluster so I can check the reverse dependencies.

Found the following significant warnings:
  /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library/RcppEigen/include/Eigen/src/Core/arch/NEON/PacketMath.h:1671:38: warning: ‘void* memcpy(void*, const void*, size_t)’ copying an object of non-trivial type ‘Eigen::internal::Packet4c’ {aka ‘struct Eigen::internal::eigen_packet_wrapper<int, 2>’} from an array of ‘const int8_t’ {aka ‘const signed char’} [-Wclass-memaccess]
  /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library/RcppEigen/include/Eigen/src/Core/arch/NEON/PacketMath.h:1716:38: warning: ‘void* memcpy(void*, const void*, size_t)’ copying an object of non-trivial type ‘Eigen::internal::Packet4c’ {aka ‘struct Eigen::internal::eigen_packet_wrapper<int, 2>’} from an array of ‘const int8_t’ {aka ‘const signed char’} [-Wclass-memaccess]
See ‘/Users/molliebrooks/Documents/glmmTMB development/glmmTMB/glmmTMB.Rcheck/00install.out’ for details.
* used C++ compiler: ‘g++ (GCC) 11.0.0 20201205 (experimental)’

[mebrooks]

Since the sun never sets on the glmmTMB development team, I'll go ahead and ask what our gameplan should be for the next 24 hours.

In terms of branches

• it sounds like Test implementation of glmmTMB leverage function #1065 is out for now.
• @mmcgillycuddy, what do you think about propto covstruc #1068 ? The conflict is trivial. Even if the checklist is incomplete, is it safe enough if we just annouce the trial status in news and warnings? Or is it safer to wait?
• @bbolker, is Save smooth info #1075 OK to merge? Or should we get info on similar packages (sdmTMB, tramME) first, to make smooths smoother going forward?
• I agree with Florian that it would be nice to get Extend RE form #1067 working enough for more DHARMa capabilities. I'm just waiting for the go-ahead.

@mmaechler or @kaskr, any idea about the CRAN warning above that I got but Ben didn't? I also got it on a slightly older version of R today before updating.

Installing everything new on DTU's new cluster is taking longer than expected, so I'm still working on setting up revdep checks .

[bbolker]

I never heard back from Gavin Simpson about #1075; I doubt it would hurt to include it ...

Unfortunately #1067 is a little bit of a mess, I'm trying to clean it up now. I have all the existing tests working now; I will try to do some very basic tests of the intended extended functionality and see how it goes ...

(I just posted a very basic example here. It's rough, but if DHARMa authors would find it useful to have it available (and be willing to update for future releases ...), and if it doesn't break anything else, I think we could include it ...

[mmcgillycuddy]

Hi @mebrooks, I think it's ok to go out for people to trial. I would just like to add something to the vignette so there is an example.

[mebrooks]

Do the GitHub actions automatically check all OS? I've been doing that using rhub for previous CRAN submission, but rhub updated to a new version which is quite different and it sounds like it may be redundant with GitHub actions.

I'm checking the reverse dependencies of the current master branch and I'll rerun them after we merge in #1067. I think it's a safe thing to do because you're just adding a new function.

[bbolker]

I'm getting a little worried now. I have to go to work and teach now and am pretty busy most of the day. I'm getting some test failures in test-propto, not sure why I haven't seen them before now. This looks like an extend_re_form-specific problem though ...

[bbolker]

It seems ridiculous, but I think our choices might be (1) hold off on extend_re_form for now (and make a concerted effort to clean it up and push a new version in a month or so), or (2) ask CRAN for a 24-hour extension ...

[mebrooks]

Ok, I wrote to CRAN for an extension and will keep you updated.

I can't figure out this warning. When I had a similar problem before it was fixed by using CRAN's version of TMB, but that doesn't seem to be working.

I'll keep testing and trying.

[mebrooks]

Kasper says the warning I was getting looks like a problem in Eigen, so there's nothing we can do to fix it:
https://gitlab.com/libeigen/eigen/-/issues/2326
And it would occur on any package that links to RcppEigen.

The reverse dependency checks are still running so I'm going to take a break and come back in an hour. I tried to understand the errors that extend_re_form causes in test-propto.R, but they're burried pretty far down.

[mebrooks]

We got a 1 week extension! Amazing.

[mebrooks]

The only problems with reverse dependencies of the current main branch (extend RE form not yet merged) are ones that we saw in the summer. So I think I just have to write to those maintiners and tell them our plan to submit this week.

UPDATE: I wrote to them.

[bbolker]

I think I've fixed the problems in the extend_re_form branch. @mebrooks are you willing to merge that PR and re-run the reverse dependency check again? (presumably now that you have it set up it will just be more compute time, not a big hassle for you to get it started .. ??)

[mebrooks]

Yeah, the reverse dependency check is not much work now that it's set up. I'm running them now and should have results in the morning.

[mebrooks]

All the revdep and Winbuilder checks are OK. So we just have to decide if we should include #1097 and address #1099. Then of course I'll do the checks again. I have about 3 hours tomorrow to work on this.

[bbolker]

I don't think either #1097 (too preliminary, untested) or #1099 (bug is in reformulas, can be fixed elsewhere, predates this release) are worth worrying about for this release.

You might want to comment that the dotwhisker package, while currently archived, is actively working to get back on CRAN, so should be back shortly.

[mebrooks]

I submitted and told mtscr.

[strengejacke]

In the docs fpr ?nbinom12, that family could be moved to the other nbiom-entries. Currently, nbinom1 and 2 appear at the top of the list, nbinom12 at the end.

[strengejacke]

If you haven't submitted yet - I found a bug, possibly in the tweedie family. Let me file an issue.

[strengejacke]

(ok, just saw, I'm 3 hours late: https://r-hub.github.io/cransays/articles/dashboard.html)

[bbolker]

In the docs fpr ?nbinom12, that family could be moved to the other nbiom-entries. Currently, nbinom1 and 2 appear at the top of the list, nbinom12 at the end.

FWIW I think this has to do with the order that the functions actually appear in the code (since they're all defined with an @rdname nbinom2 roxygen tag ...)

[strengejacke]

FWIW I think this has to do with the order that the functions actually appear in the code (since they're all defined with an @Rdname nbinom2 roxygen tag ...)

Yes, I know, but that's probably not what users see/know ;-)