Procedure for Handling Dual Refactors

[Michael Betancourt]

Right now there are two big, concurrent refactors:

https://github.com/stan-dev/stan/tree/feature/issue-1361-writer_callback

Substantial refactor of the API into services and interface callbacks,
implementing a writer callback to remove any system I/O dependencies.

and

https://github.com/stan-dev/stan/tree/feature/refactor_io_reader_writer

Refactors var_context, eventually will clean up the
generated model code and completely template out
most of the services.

Already there have been merges that will conflict with these refactors,
but my main concern right now is whether to try to keep these
refactors together or not. Propagating changes to the var_context
implementations will require changing command/services which
would have to be rewritten unless the first branch is merged first.

I see a few possible means of moving forward:

1) Keep these separate branches independent of each other and
just swallow a nasty merge process down the line.

2) Merge the writer_callback after 2.7.

3) Create a Stan3 branch, merge the writer callback into that
and then work the var_context refactor off of this new Stan3
branch.

How should we do this? Either way there’s going to be a few
big merges that we’ll have to muck through given how much code
is getting changed.

[Allen B. Riddell]

Option #3 makes sense to me. I've already been thinking of both
refactor branches as part of the stan3 refactor.

[Bob Carpenter]

All else being equal, we want small pull requests.

So I'd recommend doing one first rather than working
in parallel, so that merge is less nasty. I think
that's your option (2).

All else not being equal, it's not the end of the world
if you put them together to save your sanity.

- Bob

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

[Daniel Lee]

I'd suggest making conceptually smaller branches. Then it's easy enough to daisy chain the branches.

For example, if you wanted to add tests for scaffolding, do that on a branch first, and get that a stand-alone pull request. If you find a problem with some portion of the code and want to change it, instead of rolling it into a larger pull request, get that on a separate one and merge that into your branch and get the pull request going.

For the writer_callback branch, I really want to break it into a handful of pull requests. I've just been wrestling with the math library, so I haven't had the chance to do it myself.

Daniel

[Michael Betancourt]

It’s really just a question of how long the conversion from 2.7 to 3.0
will be and if there will be a bunch of new stuff added post 2.7.

[Daniel Lee]

Sorry, what's the question? I don't know what the timing is between now and 3.0, but I think regardless, we can merge smaller pull requests into Stan, or am I missing something?

Daniel

[Michael Betancourt]

There is no easy way to break these into smaller pull requests —

the changes are too interconnected.  If someone wants to try to

do that, fine, but I think that it’s a complete waste of time.  Once

we have working refactors in we can add tests and such in waves

of smaller commits.

And this doesn’t even consider the interfaces.

Basically I do not want these refactors to wait for other things —

if that means having a Stan3 branch that incorporates all of the

refactors (and eventually argument changes) while the interfaces

work off of 2.7+ fine.

[Ben Goodrich]

On Monday, July 6, 2015 at 11:56:32 AM UTC-4, Michael Betancourt wrote:

And this doesn’t even consider the interfaces.

Basically I do not want these refactors to wait for other things —

if that means having a Stan3 branch that incorporates all of the

refactors (and eventually argument changes) while the interfaces

work off of 2.7+ fine.

I (and I think Allen would agree) wouldn't mind a Stan3 branch. I started to make some skeleton code for rstan3, but there is currently a giant hole in the middle of it where "call the C++" would go. I'm sure it will work, but I'm not exactly sure how. So, it would be good to be able to play with that in a branch as it is taking shape.

Ben