I’ve actually been thinking about this a lot over the past few days, but haven’t come to any real conclusion yet.
The way I’ve traditionally worked on Foundation is that each commit has more content, and each commit is (almost) always associated with a bug. This is basically the process I had in mind when I wrote the CONTRIBUTING document.
However, we’re at such an early stage in this project now that I don’t want to add a lot of overhead to PRs that contain basic functionality. I’m also grateful for all of the work that everyone is putting in, and don’t want to put off potential contributors with an overly pedantic policy. We’re trying as hard as we can to keep up with everything, but some PRs are sitting for some time before we can fully review them, which means they are inevitably out of date and have to be rebased.
I think that as more projects start to depend upon the library we will have to be much more cautious about how we accept changes, how they are tested, and how they are structured (e.g., for easier reverting).
I welcome additional thoughts on this topic.
On Dec 17, 2015, at 1:25 AM, Tom Jowett via swift-corelibs-dev <firstname.lastname@example.org> wrote:
I'm wondering if there's a way I can help to keep the commit structure of the repo a bit tidier? I can see the guideline being provided on CONTRIBUTING.md however the current commit history could be a little easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate commits, e.g) and it seems the rebase before PR element of that guideline could be better followed.
Perhaps a link in CONTRIBUTING.md to a walkthrough on how to squash and rebase commits (including adding tests appropriately for bisect) could be helpful? Happy to put one together in the context of this project if you think so. Also interested in any other suggestions you might have for how this could be remedied.
swift-corelibs-dev mailing list