> 18. Pull Requests should be as small as possible and focused on only > one functional change. Different functional changes should be provided > in separate Pull Requests. Remember that breaking changes are not > welcome. Pull Requests must not break overall build, runtime, and > compatibility, especially for other components. When changes must be > bundled together in order to maintain functionality and > self-compatibility, exception can be made, and this must be clearly > stated there is no other way.
0: Does this apply to the documentation as well (discussed in a different thread for LTS)? I prefer to put the docs in one PR instead of creating the second one. We have a documentation in a single repository (compared to other projects like RTEMS for example), so let's take the advantage of it. Otherwise we can split the code and documentation into two repositories. But that's harder to maintain. Also another example is the implementing a new peripheral for some MCU. This implementation SHOULD come with another commit that adds the support for it to BSP, otherwise the CI jobs for the peripheral are useless, the new code is not build at all. > 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. -1 in case we don't require 4 reviewers for every PR, but only for major and potentially breaking ones, otherwise +1. Michal On 2/12/25 11:37, Tomek CEDRO wrote: > Lets add these two points to vote that came out of the discussion and > see the reaction. > > This vote is to see what subjects we do agree already and what needs > update / clarification :-) Where are all +1 we can implement already, > where is at least one -1 that needs fix, where is 0 we may clarify > some information with the feedback provided :-) > > > 18. Pull Requests should be as small as possible and focused on only > one functional change. Different functional changes should be provided > in separate Pull Requests. Remember that breaking changes are not > welcome. Pull Requests must not break overall build, runtime, and > compatibility, especially for other components. When changes must be > bundled together in order to maintain functionality and > self-compatibility, exception can be made, and this must be clearly > stated there is no other way. > > > 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. > >
