Hi! Tomek, there is an important missing point about 19 (that is part of my proposal):
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. It's missing that a PR has to be *eligible *for requiring it and this includes some specific situations: - It should not affect more than one chip/board; - It applies to new features and apps that have no associated breaking changes and backward compatibility; - It requires at least one independent reviewer; - It requires an extensive testing section and proper documentation. These are *mandatory *conditions and we can vote it without it (this was part of my considerations about *Lazy Consensus*). I would be against proposition 19 it if these requirements are missing. Can you please update proposition 19 and reconsider your vote based on the requirements? Em qua., 12 de fev. de 2025 às 09:32, Michal Lenc <michall...@seznam.cz> escreveu: > > 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. > > > > >
