On Mon, Mar 9, 2020 at 12:52 PM Justin Mclean <jus...@classsoftware.com> wrote: > > Hi, > > > I basically agree with most of the things you say here, but in an Apache > > project, you cannot set rules unilaterally. No one person has that > > authority over the project. We all all equals. Decisions can only be made > > with concurrence from other team members and we can only get concurrence > > through a full vote. > > Refining that a bit. It true no one has authority but it's best to try and to > reach consensus by discussion. Voting too often or too early makes winners > and losers and splits the community. Vote when done is usually made to > confirm that consensus and when called teh outcome is already known. >
Yes, that is why I send this email to get the community feedback. To avoid the topic extend to the unrelated field, let's just focus on one thing I suggest: The github action just check the coding style for the modified lines in the patch, not the whole source lines. Here is the several reasons: 1.It's hard to review the real change if we mix the style change in PR, here is two examples: https://github.com/apache/incubator-nuttx/pull/492 https://github.com/apache/incubator-nuttx/pull/495 The change in these two PR is simple: 1.Fix the warning: implicit declaration of function 'uart_earlyserialinit' 2.Change the argument and return of spi_send from uint16_t to uint32_t But it is very hard to review now because more than 90% change is to fix the style issue. 2.The github action still ensure the modified lines confirm the coding standard, so the relaxtion don't make the situation worse. 3.The contributor or committer still can create the dedicated patch to fix the style issue. Please reply with your reason here if you have different opinion, so the community can get more thought. > I would not suggest having a vote on this in such a short time frame. > How much time should we wait before starting a vote? > Thanks, > Justin