Re: [DISCUSS]: Self merge and Single company/organization merge gating

2022-02-17 Thread Petro Karashchenko
Hi, I agree that auto-merge should not be used. But I disagree that "as it is now since almost all patches follow the rule and seldom someone self-merges a patch". Here is a list of patches that were self merged last 12 days: https://github.com/apache/incubator-nuttx/pull/5474 https://github.com/

RE: [DISCUSS]: Self merge and Single company/organization merge gating

2022-02-17 Thread alin.jerpe...@sony.com
Hi all In my opinion we should not use the auto merge functionality since most of the time there is at least 1 of us active at any time and the amount of patches is not comparable to EX: Google. I think that the merge policy is fine as it is now since almost all patches follow the rule and se

Re: RE: [DISCUSS]: Self merge and Single company/organization merge gating

2022-02-17 Thread Jukka Laitinen
Just my two cents, I like the self-merge policy. I am using it in all the repos where I can decide. My take on it is that it leaves the final responsibility for the change to the PR creator. And at the same time it doesn't take away the authority of the approvers. While the responsibility is

RE: [DISCUSS]: Self merge and Single company/organization merge gating

2022-02-17 Thread David Sidrane
On Self merge: As Nathan pointed out, it is more about time zones then merge velocity. However, using a backport only methodology requires an upstream merge before the work can be backported with least effort and adds a serial delay. It would be ideal to reduces the CI quantum delay this as much a

Re: [DISCUSS]: Self merge and Single company/organization merge gating

2022-02-17 Thread Petro Karashchenko
Hello, Regarding PRs megre by the author: I think that if the changes are relatively simple (again that is very subjective, but I hope that people with merge rights have more or less the same common sense of it) and there is an approval from outside of the company/organization then the author can

Re: [DISCUSS] Default state of NDEBUG

2022-02-17 Thread Petro Karashchenko
Hello. My point about two config options was more because I think that apps and kernel are two separate entities and if there is a need to add extra debugging capabilities to the kernel it does not mean that it needs to be added for apps as well and vice versa. This seems to be right to me from th

Re: [DISCUSS] Default state of NDEBUG

2022-02-17 Thread Juha Niskanen (Haltian)
NDEBUG is just one macro name. I feel it is silly to have either one or two CONFIG macros to control whether or not it is defined or not. My preference is zero new CONFIG macros. We have too many already and trend seems to be remove ones that disable standard POSIX features (CONFIG_DISABLE_SIGNA