I’d like to set up a monthly planning meeting just for the Math library. I would like to default to a 30 minute meeting. We can always add additional meetings if necessary. If anyone would like to join me, please let me know.
At these meetings, I’d like to:
take a snapshot of the state of the Math library; open issues, open pull requests, any hurdles, etc.
assign tasks; this may be things like reviewing pull requests, figuring out who needs help in development, etc.
try to find actionable ways to improve the math library
Once I have a sense of who wants to meet, we can try to schedule something with those interested.
@seantalts, mind filling in whatever questions you have that I didn’t write down?
This will go on the Math wiki.
We should encourage more people to review code. We can do this by splitting apart reviewer tasks across different people since a lot of pull requests are multi-faceted.
We discussed the next release of Math and Stan. We will release Math v2.18.0 and Stan v2.18.0 when CmdStan has MPI ready to go.
For the 1-d integrator pull request, we need to go through and see if a decision has been made regarding Boost. If it hasn’t, we need to clearly come up with a decision. If it has, we need that to be clear.
We currently have:
149 open issues
12 open pull requests
only 7 pass tests
Some other things we need to do:
prioritize what we should work on for the Math library
I thought we decided to go with the Boost version and we were going to let Marco know and Ben Bales was going to take over the issue.
If that’s not the decision, can you indicate what needs to be done to enable a decision?
Until new governance lands, the final decisions of what to do and how to do them are up to you. Obviously, you want to use a light touch here and let the developers make most of the dev-oriented decisions. What we need are clear decisions about what to do. So these two are important:
@bgoodri believes we can go with Boost for the implementation
@bbbales2 has volunteered to implement this summer using Boost
Can someone verify that the Boost implementation is good enough for us to use and replace our current implementation?
That’s all I need to enable the decision. That Boost is good enough to use and replace our current implementation. I’d just really like an explicit “yes” from someone that’s looked into it. Reading the thread without knowing the implementation, it looked like a “definite maybe” – sounded like it was more advanced in ways, but behind in others. I don’t know if it’s behind in critical ways.
So… @bgoodri, do you think that the Boost 1-d integrator covers our current use case for the 1-d integrator?
This makes it sound less like we need a decision and more like we need: 1) some tests of what the two integrators can handle; and 2) figure out what types we need the integrator to handle.