bigger code changes
Sebastian Weber
I was wondering if for bigger changes to Stan it would make sense to depart slightly from our current model.
The problem I see with the current model is that we enforce merging with develop which has the obvious requirement that all tests need to be in place and nicely return successful. This can be very work heavy to do in particular if a change is large and moves things around, breaks tests, etc..
How about we do the following for bigger changes:
- branch off from develop onto a develop-feature-XXX branch
- branch off from develop-feature-XX to feature-XXX-task1
- develop there and then make a pull which merges into feature-XXX-task1; without the high requirements of having all tests being ok (remember, this is not going into develop)
- repeat that for task2,3,4
- finally make a pull for the develop-feature-XXX which then will be merged into develop AND must, of course, come with a complete set of tests
Just a thought as to how larger changes could be brought into Stan. I am not saying that no tests should be written in between, they should; but sometimes we need a new structure and keeping everything in sync cost us a lot of work.
I think it would possibly make large refactors easier.
Sebastian
Bob Carpenter
But what's the motivation for the pull requests if they don't
have passing tests? They're hard to review without them.
- 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.
Sebastian Weber
Going in smaller steps here maybe would have helped making this process more efficient. Even after having designed the bdf integrator system, I still find myself writing lots of code which is deemed not appropriate.
My intention is to increases the chances for accepting contributions (and facilitate the possibility to do larger changes). Of course, this should not mean that long-term Stan devs (like you/Daniel/Michael/anyone I missed) should hold hands with newbies all the time, but increasing chances for accepting contributions would be great.
And what big is, will be relative to the developer - I would never dare to submit a pull request like Daniel just did with the refactor.
Sebastian
On Tuesday, August 16, 2016 at 4:59:11 PM UTC+2, Bob Carpenter wrote:
> It's fine to do the development in incremental pull requests.
> But what's the motivation for the pull requests if they don't
> have passing tests? They're hard to review without them.
>
> - Bob
>
> > On Aug 13, 2016, at 1:09 PM, Sebastian Weber
> >
Bob Carpenter
> On Aug 16, 2016, at 5:23 PM, Sebastian Weber <sdw....@gmail.com> wrote:
>
> It would help someone like me to not derail to far off from common Stan standards which I just don't know. I found myself fixing many tests as I wrote code or adapted code. Much of this work was burned because conceptually things were not aligned with Stans internal design - which I simply did not know.
>
> Going in smaller steps here maybe would have helped making this process more efficient. Even after having designed the bdf integrator system, I still find myself writing lots of code which is deemed not appropriate.
>
> My intention is to increases the chances for accepting contributions (and facilitate the possibility to do larger changes). Of course, this should not mean that long-term Stan devs (like you/Daniel/Michael/anyone I missed) should hold hands with newbies all the time, but increasing chances for accepting contributions would be great.
want contributions to be accepted---it's less work for everyone that way.
We can also comment on draft branches if you like, but if you'd rather
do it with multiple pull requests, that's fine.
> And what big is, will be relative to the developer - I would never dare to submit a pull request like Daniel just did with the refactor.
- Bob