I think this is fine how you have it.
Here, dirty wasn’t what I was trying to get across. It’s just a lot of chatter recently about Jenkins. I’m not saying anything is broken or should have been done differently! (What I think would have been clean is if we had pipelines working before cutting over pieces at a time and having the new box tested on dummy projects before bringing them into our testing framework.)
Sorry if it seems as if I’m painting that picture. Sometimes it’s really hard to communicate intent over written communication.
The point about
develop being stable is that up until now, we’ve explicitly stated in our doc (Stan manual), we’ve assumed it was true, and we’ve tried, to our best effort, to keep
develop on Math and Stan in a good state. It wasn’t always that way, but we switched to that model a while ago. It was something the devs at the time sat down and we discussed. We weighed the pros and cons (at the time, which are very different from now), and that’s what we did.
Deviating from that knowingly seems like a very big change that we should give the same amount of respect. Everything that makes Math and Stan safer isn’t really a policy change. Going from as-safe-as-we-know-how to something less than that is something we should discuss. I’m not opposed to it, but I think we should just slow our roll before making this decision. I know we wouldn’t have made as much progress to this point if it weren’t stable, so before we change that, we should just think hard about it. (I’m ok with the change once we really evaluate it.)
? I don’t think that was true:
- the PR in math kicked off tests that includes upstream tests for Stan (testing develop with the PR merged in), then for CmdStan (with Stan with the Math develop with the PR merged in)
- after the PR is merged, this used to create a PR from Math to Stan with the updated submodule. This is where the branch would again be tested again Stan and CmdStan.