Hi Andrea, Thanks! After we get a consensus, I'll make sure we document that on the contributor guidelines, so we have something to refer to and everyone knows the expectations.
Kind regards On Wed, Jul 19, 2023 at 10:47 AM Andrea Cosentino <anco...@gmail.com> wrote: > 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 > > > -- Otavio R. Piske http://orpiske.net
