Hi Ad 1) For basic stuff like a polish or update in a readme / doc file then direct push can be okay.
However the GA action has improved a lot in recent time, so the time it takes for it to complete and the feedback it gives now is more trustworthy. Ad 2) Yes this is good practice to squash - on GH I always click the "squash and merge" button. However locally I do individual commits while working on stuff, as sometimes I need to easier diff what I changed since something last was working etc. On Wed, Jul 19, 2023 at 10:38 AM Otavio Rodolfo Piske <angusyo...@gmail.com> wrote: > 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 > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
