Hi all, I agree with David but in my opinion this information should go in the commit message and no commit without message should be merged. Not all people will check the PR message but you will always see the reasons simply by typing "git log" if they are in the commit message
What do you think ? Thanks Alin -----Original Message----- From: David Sidrane <david.sidr...@nscdg.com> Sent: den 9 mars 2023 10:00 To: dev@nuttx.apache.org Cc: Sebastien Lorquet <sebast...@lorquet.fr> Subject: RE: DISCUSSION - Usage of mailing lists for apache projects I would add that all pull request must have a statement explaining the reason or motivation for the change(s). Just stating the "What" was done is not enough. There must be a "Why" the change is needed. David -----Original Message----- From: alin.jerpe...@sony.com <alin.jerpe...@sony.com> Sent: Thursday, March 9, 2023 3:39 AM To: dev@nuttx.apache.org Cc: Sebastien Lorquet <sebast...@lorquet.fr> Subject: RE: DISCUSSION - Usage of mailing lists for apache projects 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. >
