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 [email protected] <
[email protected]> 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 <[email protected]>
Sent: den 9 mars 2023 10:12
To: [email protected]
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 [email protected] <
[email protected]> 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 <[email protected]>
Sent: den 8 mars 2023 19:15
To: [email protected]
Cc: Sebastien Lorquet <[email protected]>
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 <[email protected]> wrote:
On Wed, 8 Mar 2023 at 09:55, Alan C. Assis <[email protected]> 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.
