Re: NuttX Code Quality Improvement 2025Q1

2025-02-12 Thread Tomek CEDRO
I am redirecting questions from Takashi to this thread :-) On Wed, Feb 12, 2025 at 6:45 AM Takashi Yamamoto wrote: > On Tue, Feb 11, 2025 at 8:37 AM Tomek CEDRO wrote: > > 7. Each git commit message must consist of topic, description, and > > signature, which are mandatory, or change is auto-rej

Re: NuttX Code Quality Improvement 2025Q1

2025-02-11 Thread Tiago Medicci Serrano
Hi, What is the goal of lazy consensus? Faster merge? This is what we are > trying to prevent I think. Sorry Sebastien, it seems you didn't read my considerations. It isn't about merging faster. Is about merging even after calling for help. If we have a feature (likely a new feature) that does

Re: NuttX Code Quality Improvement 2025Q1

2025-02-11 Thread Sebastien Lorquet
What is the goal of lazy consensus? Faster merge? This is what we are trying to prevent I think. I promise you, if there is a loophole in the process, it will be exploited. Better start strict and keep some room to adapt if we find problems, than allowing an absence of review from the very st

Re: NuttX Code Quality Improvement 2025Q1

2025-02-11 Thread Tiago Medicci Serrano
Hi, just an additional comment: Lazy consensus is exactly what lead to absence of any testing and breakages. This *Lazy consensus *is just about the timeframe and the lack of 4 reviewers. The PR should be compliant with all other requirements (description, testing, documentation etc). My propos

Re: NuttX Code Quality Improvement 2025Q1

2025-02-11 Thread Tiago Medicci Serrano
Hi! I agree with almost every single point from Sebastien and Tomek: Lazy consensus is exactly what lead to absence of any testing and breakages. > This isn't entirely true. *Lazy consensus *is very bad if it affects a lot of people, but the Wi-Fi support for all Espressif chips was added with i

Re: NuttX Code Quality Improvement 2025Q1

2025-02-11 Thread Tomek CEDRO
On Tue, Feb 11, 2025 at 12:40 PM Tiago Medicci Serrano wrote: > Two points that seem to be missing in the current *[VOTE] NuttX > Contributing Guidelines update 202502.* thread: > > About commits... > > We were discussing splitting some changes into different PRs, adding the > commit's message and

Re: NuttX Code Quality Improvement 2025Q1

2025-02-11 Thread Sebastien Lorquet
Hello, I am adding a negative opinion to this. Lazy consensus is exactly what lead to absence of any testing and breakages. If something is not looked at, it MUST NOT be integrated silently. It must be delayed until someone looks at it. If no one acts, the mailing list can be called for acti

Re: NuttX Code Quality Improvement 2025Q1

2025-02-11 Thread Tiago Medicci Serrano
Hi, Two points that seem to be missing in the current *[VOTE] NuttX Contributing Guidelines update 202502.* thread: About commits... We were discussing splitting some changes into different PRs, adding the commit's message and description, etc but I couldn't find anything (even on Docs) that men

Re: NuttX Code Quality Improvement 2025Q1

2025-02-10 Thread Tomek CEDRO
On Mon, Feb 10, 2025 at 8:42 PM Alin Jerpelea wrote: > I thiink that we should have romething like a list and we should vote +/-1 > for each proposal then we summarize per change and we adopt the ones that > pass with +3 > I fear that if we start 10+ votes we may miss to vote on some. > What do yo

Re: NuttX Code Quality Improvement 2025Q1

2025-02-10 Thread Alin Jerpelea
I thiink that we should have romething like a list and we should vote +/-1 for each proposal then we summarize per change and we adopt the ones that pass with +3 I fear that if we start 10+ votes we may miss to vote on some. What do you think? what would be easyer? Best regards Alin On Mon, 10

Re: NuttX Code Quality Improvement 2025Q1

2025-02-10 Thread Tomek CEDRO
On Mon, Feb 10, 2025 at 2:44 PM Alin Jerpelea wrote: > Hi Tomek, > can you start a vote tread with the discussed changes so that we can > implement them Sure Alin, will do in a free moment :-) Do we want to vote per change separately or all of them in one place? -- CeDeROM, SQ7MHZ, http://www.

Re: NuttX Code Quality Improvement 2025Q1

2025-02-10 Thread Alin Jerpelea
Hi Tomek, can you start a vote tread with the discussed changes so that we can implement them Thanks Alin On Thu, Feb 6, 2025 at 8:00 PM Tomek CEDRO wrote: > On Thu, Feb 6, 2025 at 7:50 PM wrote: > > > One word answer: electron. > > No more explanation needed :D > > I use discord over web br

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Tomek CEDRO
On Thu, Feb 6, 2025 at 7:50 PM wrote: > > One word answer: electron. No more explanation needed :D I use discord over web browser.. just like the rest of js crap :-P > > And mandatory link because IRC was mentioned: https://xkcd.com/1254/ > I made a mistake, it was supposed to be this one :P ht

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread michal . lyszczek
On 2025-02-06 19:47:28, michal.lyszc...@bofc.pl wrote: > On 2025-02-06 18:48:18, Tomek CEDRO wrote: > > On Thu, Feb 6, 2025 at 4:51 PM wrote: > > > On 2025-02-06 08:43:34, Michal Lenc wrote: > > > > > Also it will be nice to have monthly online meetings just to talk > > > > > things over and stay

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread michal . lyszczek
On 2025-02-06 18:48:18, Tomek CEDRO wrote: > On Thu, Feb 6, 2025 at 4:51 PM wrote: > > On 2025-02-06 08:43:34, Michal Lenc wrote: > > > > Also it will be nice to have monthly online meetings just to talk > > > > things over and stay connected and synchronized. It should bring > > > > community clo

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Alan C. Assis
+1 - We need more and better documentation! - We need to keep existing documentation up to date after modifications. I think all reviewers should pay attention to it and have the courage to ask it to the PR author (I know it is kind of uncomfortable to ask for, but we need to do it for the quali

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Tomek CEDRO
On Thu, Feb 6, 2025 at 4:55 PM Matteo Golin wrote: > If I may add to the proposed contributing guideline changes: all changes > affecting behaviour/APIs or adding features should be properly documented, > not just within the PR. NuttX has many features and lots of apps for using > them, but a lot

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Tomek CEDRO
On Thu, Feb 6, 2025 at 4:51 PM wrote: > On 2025-02-06 08:43:34, Michal Lenc wrote: > > > Also it will be nice to have monthly online meetings just to talk > > > things over and stay connected and synchronized. It should bring > > > community closer together :-) > > > > Yes! We have to find a prope

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Tiago Medicci Serrano
Hi! * if after a week the pull request does not have the required approvals, > the issue is brought on the mailing list for further discussion. Particularly, I don't like the idea of "lazy consensus" too. I think we can try to actively ask for more reviewers (in the list and on GH). I dont unde

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Tomek CEDRO
On Thu, Feb 6, 2025 at 4:10 PM Alan C. Assis wrote: > * If one person approves a PR and no other reviews or objections after a > week, the person who approved the PR can assume a "lazy consensus" and go > ahead and merge. Im not sure if this is safe. We can always ask for request directly from gi

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Sebastien Lorquet
Hello Alan, and Tomek, Is this a good rule? I have the feeling that any pull request could come with unexpected problems, and if no one reviews it, it does not mean that the problems are going away. As suggested by anchao in previous emails, this is what happened in the spinlock issue. No o

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Matteo Golin
Hello, If I may add to the proposed contributing guideline changes: all changes affecting behaviour/APIs or adding features should be properly documented, not just within the PR. NuttX has many features and lots of apps for using them, but a lot of them are left undocumented outside of inline comm

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread michal . lyszczek
On 2025-02-06 08:43:34, Michal Lenc wrote: > > Also it will be nice to have monthly online meetings just to talk > > things over and stay connected and synchronized. It should bring > > community closer together :-) > > Yes! We have to find a proper channel for this though. I think there > were

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Alan C. Assis
Hi Tomek, You missed that rule: * If one person approves a PR and no other reviews or objections after a week, the person who approved the PR can assume a "lazy consensus" and go ahead and merge. BR, Alan On Thu, Feb 6, 2025 at 12:46 AM Tomek CEDRO wrote: > Hello world :-) > > We have long d

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Tomek CEDRO
On Thu, Feb 6, 2025 at 10:20 AM alin.jerpe...@sony.com wrote: > I would propose that we refine the review requirement and demand less reviews > for boards and areas that have limited scope while increasing the number for > common areas that have a wider scope : ex arch, drivers, frameworks. In m

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread Tomek CEDRO
On Thu, Feb 6, 2025 at 9:30 AM raiden00pl wrote: > >On Thu, Feb 6, 2025 at 8:45 AM Michal Lenc wrote: > > Perhaps I would limit this to larger commits only (and all affecting > Build / Kernel / common arch code of course). GitHub bot tells you the > size of the pull request, so we can draw some l

Re: NuttX Code Quality Improvement 2025Q1

2025-02-06 Thread raiden00pl
> Perhaps I would limit this to larger commits only (and all affecting Build / Kernel / common arch code of course). GitHub bot tells you the size of the pull request, so we can draw some line according to that. And maybe it could also automatically set the mandatory number of reviewers. This way s

Re: NuttX Code Quality Improvement 2025Q1

2025-02-05 Thread Michal Lenc
Hi Tomek, I think most of the points make sense, just few notes to some of them. > * Number of required code reviews should be increased from 2 to 4. > This will ensure cross-checks and filter out faulty changes. Perhaps I would limit this to larger commits only (and all affecting Build / Kernel

Re: NuttX Code Quality Improvement 2025Q1

2025-02-05 Thread Tomek CEDRO
On Thu, Feb 6, 2025 at 4:45 AM Tomek CEDRO wrote: > We have long discussions over the last months NuttX code quality and > self-compatibility degradation. I think open discussion in this area > as for 2025Q1 can be constructive. Please join the discussion :-) > (..) There are separate mailing lis