Hi folks, I am writing this proposed changes based on the feedback received on the previous email where I shared some thoughts/concerns about improving our contribution practices (see the email entitled "Some thoughts on bisecting Camel and our git commit practices" for details).
This is mostly aimed at the Camel Core sub-project (potentially, we can use it later for Camel Spring Boot, Camel Kafka Connector, and Camel Karaf). My understanding is that there are 2 practices we can start using that can improve the quality of our commits and ensure our commits are compilable and easy to bisect. 1. All code changes should done via Pull Requests: The idea is to reduce the incidence of non-compilable commits by ensuring that any code goes through Github compilation and testing. This helps both the contributors, by ensuring their contributions are complete and testable as well as the rest of the community, by ensuring that the code doesn't break the tree for others 2. Squashing as the default way of merging code The idea is to make sure that the contribution is seen as a single unit of change, including the build result of the contribution which reflects the final state of the branch. There may be a few cases where going through this process might be a bit too much. For instance: changing the code for CI automation, modifying code that is clearly not compilable (i.e.: readme files or other text files that are not documentation for the website, but provide support for developers, etc). I suggest we use the same approach for these files, but don't necessarily make ourselves bound to wait for the GH CI to run before merge. Please, what do you think about this? If there's agreement, how could we possibly start using this process? Kind regards -- Otavio R. Piske http://orpiske.net
