I propose to wait for the feedback and do not modify the current vote
already launched. After vote completes we have summary, discussion,
send PR with updated guide propositions and discuss the PR to close
the subject.
I have updated rule 14 with propositions gathered feedback. We stay
with 2 revi
Hi Tomek, thanks for all the effort ;)
About proposal 19, I suggested it and dropped it in favor of Nathan's
approach (which Raiden might be favorable as well). Can we reflect it on
the forms?
The current proposal 14 is about the necessary reviewers. The current text
would be 14.1 and Nathan's al
Thank you Tiago! I have prepared a google form with all questions 1-19
updated based on our discussions, I will post it now as separate
thread so it is not missed, hopefully this way will help in results
gathering and presentation and there are optional fields where anyone
can propose better textin
Hi all!
About the pending proposals, can we proceed to another vote round?
I think we should wrap up it subject and create the article in the docs as
soon as possible...
Are we waiting for something else?
Best regards,
Em ter., 18 de fev. de 2025 às 09:45, Tiago Medicci Serrano <
tiago.medi...
Hi!
So is it okay to keep 2 reviewers for version bumps and documentation
> updates and 4 for the rest? Maybe its good to have two rules: 2
> reviews for trivial updates like version bumps and documentation
> update (what else?) and 4 reviews for all other PRs?
IMHO, It's still too restrictive.
On Mon, Feb 17, 2025 at 12:20 PM Tiago Medicci Serrano
wrote:
> Hi!
> Thanks, Tomek, for summarizing it.
>
> I liked Nathan's proposal. Instead of simply increasing the number of
> reviewers from 2 to 4, we can adopt tags (we can even evaluate if the bot
> can do it automatically), and, based on s
Hi!
Thanks, Tomek, for summarizing it.
I liked Nathan's proposal. Instead of simply increasing the number of
reviewers from 2 to 4, we can adopt tags (we can even evaluate if the bot
can do it automatically), and, based on such categories, we have new
requirements for the reviewers.
Considering
Thank you Nathan :-)
I just noticed that we missed self review can be added to 17 :-P
I am allergic to bureaucracy myself. All this is to improve project
quality not to make life harder. But also avoid obvious situations
like self merging, sending untested changes, making breaking changes
standar
On Sat, Feb 15, 2025 at 4:53 PM Tomek CEDRO wrote:
>
> Okay so here goes the vote results :-)
Thanks, Tomek, for doing all of this!
I would like to add some more of my thoughts:
Regarding these rules:
9. Zero trust approach to user testing
10. Breaking changes not welcome.
11. Respect for long
Okay so here goes the vote results :-)
Lets turn this thread now to a discussion that should end up with all
down voted points clarified and cast to vote again.
Another question right now do we want to add +1 points already to
Guidelines or wait for all list to clarify? Some fine tuning of the
te
> We can't stop going forward, but this item can be reviewed in the future,
> when more people are working in Nuttx.
>
>
> From: Tiago Medicci Serrano
> Sent: Thursday, February 13, 2025 9:24 AM
> To: dev@nuttx.apache.org
> S
rward, but this item can be reviewed in the future, when
more people are working in Nuttx.
From: Tiago Medicci Serrano
Sent: Thursday, February 13, 2025 9:24 AM
To: dev@nuttx.apache.org
Subject: Re: [VOTE] NuttX Contributing Guidelines update 202502.
[Exter
My votes:
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
> compatib
you might be right, or not, I cant tell.
To be honest, I find this specific rule to be very complex. it's not
easy to understand its effect (I did not apparently)
so it should be reworded at least.
I suggest still not to integrate it as-is.
Sebastien
On 12/02/2025 19:21, Tiago Medicci Serr
On Wed, Feb 12, 2025 at 5:15 PM Tiago Medicci Serrano
wrote:
> So, rewriting 19:
>
> *19.* A PR may be *eligible* to be merged under the concept of *Lazy
> consensus* with the following conditions:
> - It affects only a single chip or board (no
> kernel/libs/upper-half drivers etc);
>
This "lazy consensus" seems hot topic, lets just gather the feedback
votes for now to see how many +1 / 0 / -1 are out there, then we will
discuss the details, everyone may have their own reasons and for sure
we can express them freely here :-)
Thanks :-)
Tomek
On Wed, Feb 12, 2025 at 7:21 PM Ti
Hi,
Again, Sebastien, read it *carefully*. It seems you are not willing to do
it.
It doesn't bypass anything:
- either the submitter still cares and will yell at people to get it
> approved
* My proposal says explicitly about this:*
The PR's author should:
> - After a week (
The goal is not to automatically merge PR, but only to avoid that some PRs
that don't reach the maximum number of reviews be allowed to be merged.
Typically, those who are most eager to impose new rules are not the same as
those who are subject to them!
BR,
Alan
On Wed, Feb 12, 2025 at 2:5
Again, I will vote against this. Not that it matters if a majority wants
to approve it.
This is a bypass of all other rules we're trying to enforce.
If such situation arise, there are two cases:
- either the submitter still cares and will yell at people to get it
approved
- either it will b
Hi!
Thanks, Tomek ;)
So, rewriting 19:
*19.* A PR may be *eligible* to be merged under the concept of *Lazy
consensus* with the following conditions:
- It affects only a single chip or board (no
kernel/libs/upper-half drivers etc);
- It implements a new feature (or app) that
On Wed, Feb 12, 2025 at 2:13 PM Tiago Medicci Serrano
wrote:
> 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.
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).
> 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, es
On Wed, Feb 12, 2025 at 11:37 AM Tomek CEDRO wrote:
> 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
Here goes my vote with too :-P
On Tue, Feb 11, 2025 at 12:37 AM Tomek CEDRO wrote:
> 1. In Contributing Guidelines we are adding additional section for
> Reviewers in order to provide complementary set of rules that should
> filter out breaking code as much as possible also on our side.
+1: This
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
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-rejected until fixed
> > / updated. Topic consists of functiona
On Tue, Feb 11, 2025 at 8:37 AM Tomek CEDRO wrote:
>
> Hello world :-)
>
> As discussed extensively in various mailing list threads we have
> gathered all additional ideas for Contributing Guidelines update that
> should improve NuttX Code Quality and self-compatibility / long term
> maintenance.
1. +1
2. +1
3. +1
4. +1
5. +1
6. +1 definitely shouldn't put runtime logs in the commit description
7. +1
8. +1
9. +1
10. -1, breaking changes shouldn't be unwelcome so long as they are
discussed an agreed upon by the community via the mailing list first. Some
criteria on what is considered suffic
1. +1
2. +1
3. +1
4. +1
5. +1
6. +1
7. +1
8. +1
9. +1 // this is something we need to improve, HW CI should confirm if a
PR is working
10. -1
In some cases breaking previous compatibility is necessary to evolution of
the project, but these breaking need to be discussed further in the
mainling lis
On Tue, Feb 11, 2025 at 12:37 AM Tomek CEDRO wrote:
> As discussed extensively in various mailing list threads we have
> gathered all additional ideas for Contributing Guidelines update that
> should improve NuttX Code Quality and self-compatibility / long term
> maintenance.
Thank you folks for
uttx.apache.org
Subject: Re: [VOTE] NuttX Contributing Guidelines update 202502.
[External: This email originated outside Espressif]
Hi,
1: +1
2: +1
3: +1
4: +1
5: +1
6: +1
7: +1
8: +1 I heavily recommend sending the documentation at the same PR.
Considering that PRs are as atomic as possible, th
lle Juven
>
> ____________
> From: Tomek CEDRO
> Sent: Tuesday, February 11, 2025 1:37 AM
> To: dev@nuttx.apache.org
> Subject: [VOTE] NuttX Contributing Guidelines update 202502.
>
> Hello world :-)
>
> As discussed extensively in various mailing li
t, BETTER.
11-16: +1
17: +1 and if this ever happens it should be severely punished.
-Ville Juven
From: Tomek CEDRO
Sent: Tuesday, February 11, 2025 1:37 AM
To: dev@nuttx.apache.org
Subject: [VOTE] NuttX Contributing Guidelines update 202502.
Hello world :-)
As d
Hello,
Thank you a million Tomek for having summed up everything.
1 +1
2 +1
3 +1
4 +1
5 +1
6 +1
7 +1
8 +1 same PR but different commits maybe?
9 +1 make sure tests are relevant to the function being tested and
provide useful coverage of the fix/feature.
10 +1 with allowing managed exc
1. +1
2. +1
3. +1
4. +1
5. +1
6. +1
7. +1
8. +1
9. +1
10. -1
Broken API, broken features and any other broken code should be removed
even if
it breaks some users code. Legacy code means more work for maintainers,
worse
code quality and inconvenience for users. It's always been like this in
NuttX,
1: +1 2: +1 3: +1 4: +1 5: +1 6: +1 7: +1 8: -1 documentation should be
provided at the same time as a separate PR with the same name and {2/2} to
indicate that they belong to the same PR. For LTS documentation may cause
merge issues and increase the maintainers workload 9: +1 10: +1 11: +1 PRs
sho
Hi,
1: +1
2: +1
3: +1
4: +1
5: +1
6: +1
7: +1
8: +1
9: +1
10: 0 these are sometimes necessary
11: +1
12: +1
13: +1
14: -1 I would still apply it only for bigger changes
15: +1
16: +1
17: +1
Thanks for organizing the vote!
Michal
On 2/11/25 00:37, Tomek CEDRO wrote:
> Hello world :-)
>
> As disc
1: +1
2: +1
3: +1
4: +1
5: +1
6: +1
7: +1
8: +1
9: +1
10: +1
11: +1
12: +1
13: +1
14: +1
15: +1
16: +1
17: +1
Thanks :-)
Lup
On Tue, Feb 11, 2025 at 7:39 AM Tomek CEDRO wrote:
> Hello world :-)
>
> As discussed extensively in various mailing list threads we have
> gathered all additional ideas
Hello world :-)
As discussed extensively in various mailing list threads we have
gathered all additional ideas for Contributing Guidelines update that
should improve NuttX Code Quality and self-compatibility / long term
maintenance.
Lets vote what we have. If anything is missing then lets talk ab
40 matches
Mail list logo
