Closed EECOLOR closed 8 years ago
That's an awesome way to go about it! It's super-TDD.
How about we feel free to merge our own pull requests, but avoid committing right to master unless there's a specific reason. It's good to have the opportunity to receive comment.
Tricky thing here is that at each commit it might be merged into master. What we could do is that I just work in this branch and push when I have another small one added. Then you can review and merge/comment at will.
I am unsure if there is a button to reopen a pull request after a merge
I must say I have to disagree with me on that last comment about the changes being mergable. It's a lot more complicated than that. On top of that, there will not be many successive changes as the tests are tricky to run and quite a lot of feature will not be implemented.
I'm very comfortable with these changes. For now, pursue whatever strategy doesn't get in your way.
I am running those tests (1000's of failures, haha) and fixing bits one commit after the other.
I wonder if it's a good idea to work with branches and pull requests for these types of commits. Some part of me thinks it's easier if we just commit directly to master. This is of course only for commits like the ones in this branch: small and single feature.
For (potential) breaking changes we can create pull requests. Or if we actually want to do some major remodeling.