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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
29 matches
Mail list logo