sorry wrong calculation, I meant 7 days * 0.5 hour * 50% * 4 weeks = 7
hours per month.
Still a lot, which could be saved by a few minutes of your company time
per week for specific PRs. Cause not all them need careful review.
Sebastien
Le 09/03/2023 à 11:49, Sebastien Lorquet a écrit :
I understand that, but also, you should not force your high-speed
development pace on other developers :)
Because it also consumes a huge resource to review your requests :-)
You asked me to spend half an hour a day on PR review, but you send
50% of all PRs, so this amounts to (7*0.5)*4 = 14 hours of free hard
work for Xiaomi each month! This is not possible without a commercial
contract.
You are the large company, you have employees and financial resources,
you should be doing the work, not project volunteers.
Sebastien
Le 09/03/2023 à 11:42, Xiang Xiao a écrit :
If so, most likely xiaomi will fork nuttx like Samuang and make our own
change. We don't want to spend the time to prepare the patch but no
feedback guarantee, since it consumes a huge resource to prepare the
patch.
On Thu, Mar 9, 2023 at 6:15 PM Sebastien Lorquet <sebast...@lorquet.fr>
wrote:
Hi,
This sounds like a corporate rule, does it? Not being critical here,
this is just to understand.
There should be no clear limit for a shared project, we just need time
to take the best decisions.
I feel that you cant force progress if there are no resources to do it.
Remember, most of us are volunteers, right?
That means you should not try to overcome volunteer availability by
enforcing decisions.
That also means you could have a company managed "staging
repository" to
match the speed you need for your internal products and roadmap, while
upstream contributions are discussed and validated.
I believe progress should happen more naturally if the issue is
presented to us with an explanation that you actually need decisions on
a point.
Sebastien
Le 09/03/2023 à 10:52, Xiang Xiao a écrit :
Yes, this is how I do normally, but we need the rule to ensure the PR
gets
progress. e.g. the reviewer needs to give the feedback in one week,
one
month or one year.
The reviewer has the rights to approve the change and also has
duties to
make progress.
On Thu, Mar 9, 2023 at 5:14 PM alin.jerpe...@sony.com <
alin.jerpe...@sony.com> wrote:
Hi Xiang,
Simply add some reviewers on the right side and they will be notified
that
someone asks them to step up
Best regards
Alin
-----Original Message-----
From: Xiang Xiao <xiaoxiang781...@gmail.com>
Sent: den 9 mars 2023 10:12
To: dev@nuttx.apache.org
Subject: Re: DISCUSSION - Usage of mailing lists for apache projects
If some PR waits for a long time without any review, how to make
progress?
For example, this PR sent two weaks ago:
https://github.com/apache/nuttx/pull/8610
On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com <
alin.jerpe...@sony.com> wrote:
Hi all,
I feel that this thread is getting too long without a real outcome
Some observations from my daily interactions with the project:
- I like doing reviews on github and I think that many people in
this
thread would agree that this flow is good.
- I like to be able to see all bugs in one place and get statistics
for the ASF reports
What I don’t feel right
- even if I spend time daily on reviewing patches there are still
changes that I miss and it is hard to get the flow on release date
- some breaking changes are not discussed enough with the community
since there are some people that do not have time to review code on
gihub.
As a way going forward I propose that we improve in 2 aspects
- All breaking commits should be discusses on dev so that people get
enough time to digest the change and even better get involved int
the
flow
- all breaking changes should be documented on the release
confluence
page before merging so that we don’t miss mentioning them on release
date.
- there should be at least 1 independent reviewer (not from the same
company) so that a patch is merged except board changes (ex an
employee from the same company merges a patch submitted by another
employee from the same company, for a board provided by the same
company)
Thanks
Alin
-----Original Message-----
From: Alan C. Assis <acas...@gmail.com>
Sent: den 8 mars 2023 19:15
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet <sebast...@lorquet.fr>
Subject: Re: DISCUSSION - Usage of mailing lists for apache projects
Hi Lwazi,
It is not sarcarm, I'm talking about facts.
Also I didn't say Sebastien points aren't valid, but is diverting
from
the real issue.
The issue is not if the discussion is happening here or there, the
Problem is that we don't have enough reviewers.
So, first step is that NuttX needs to increase the user base, but
have
few users really engaged with the project, reviewing patches every
single day.
Currently today he have few: Petro and Xiang are exceptional on this
point.
They are my inspiration to try do more!
Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to
hear
from you again! You have a great knowledge of BLE can we need! I was
expecting you to share that working example of BLE application using
our BLE stack).
BR,
Alan
On 3/8/23, Lwazi Dube <lwa...@gmail.com> wrote:
On Wed, 8 Mar 2023 at 09:55, Alan C. Assis <acas...@gmail.com>
wrote:
Sebastien,
If all the discussions that happens on github start to happen
here,
this mailing list will be just like the nuttx-commits mailing
list.
I'll take this as sarcasm. Sebastien is making a lot of valid
points, in good faith, and being dismissive does not help the
community.
