Hello Otavio, I'm answering inline.
Il giorno mer 19 lug 2023 alle ore 10:38 Otavio Rodolfo Piske < angusyo...@gmail.com> ha scritto: > 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. > I'm personally trying to open PR for any commit I want to push and the experience is good for the moment. > > 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. > We could disable the rebase and merge feature and only allow squash and merge. This is particularly important for verified commits, with rebase and merge the signature will be lost. > > 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 think we should write a paragraph in the contribution guide about this. > > 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. > Yep. > > Please, what do you think about this? If there's agreement, how could we > possibly start using this process? > +1 for me. > > Kind regards > -- > Otavio R. Piske > http://orpiske.net >
