|
Zephyr: Toolchain Working Group - Thu, 07/09/2020
#cal-notice
devel@lists.zephyrproject.org Calendar <noreply@...>
Zephyr: Toolchain Working Group When: Where: Description: Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r
________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
|
|
|
Upcoming Event: Zephyr: Toolchain Working Group - Thu, 07/09/2020 2:00pm-3:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr: Toolchain Working Group When: Thursday, 9 July 2020, 2:00pm to 3:00pm, (GMT+00:00) UTC Where:Microsoft Teams Meeting An RSVP is requested. Click here to RSVP Organizer: Maureen Helm Description: Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r
________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
|
|
|
Dev-Review Meeting Agenda Jul 9
Kumar Gala
Here’s the agenda topics for this week:
* Any PR/issues w/dev-review tag https://github.com/zephyrproject-rtos/zephyr/labels/dev-review * Any topics anyone else has. - k
|
|
|
|
Zephyr Toolchain Working Group Meeting – 09 July 2020
Rasmussen, Torsten
Agenda
Feel free to send a mail, if you would like additional topics to be discussed.
Best regards
Torsten T. Rasmussen
Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r ________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll) Conference ID: 682 738 030# Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
Torsten Tejlmand Rasmussen Senior R&D Engineer P: +47 72 89 92 47
Nordic Semiconductor Otto Nielsens veg 12, 7052 Trondheim, Norway
|
|
|
|
Re: Post 2.3.0 PR merging
Simon Glass
Hi Anas, Less scientifically I just did some reviews and perhaps half of them already had one approval. So presumably they were blocked. I guess you are saying it's only a third. OK. But that's a lot. Also with two reviewers, people can be somewhat less careful... How do you deal with the case of people being happy with it but wanting review from someone else before approving? I saw a few where it seemed no one would take the plunge. Regards, SImon
On Tue, 7 Jul 2020 at 12:57, Nashif, Anas <anas.nashif@...> wrote:
|
|
|
|
RFC: API Change: watchdog: wdt_feed error codes
Peter A. Bigot
Following https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html#stable we have a need to make a small change to the watchdog API that meets the criteria of "...forces users to modify their existing code in order to maintain the current behavior of their application".
Please see: https://github.com/zephyrproject-rtos/zephyr/issues/26708 Peter
|
|
|
|
New topic branch: topic-usb
Carles Cufi
Hi all,
The current subset of USB device classes implemented by Zephyr is now fairly complete, so we are ready to tackle the long needed cleaning up of the USB structures and classes that the USB maintainers have wanted to do for a while now. I have therefore created a topic-usb branch to prototype and later implement the required changes in the USB API to finally clean up the cruft that has been building up over the years, and add support for the type of functionality that has been long requested but we never had the time for. If you are interested in the changes to the USB structures and APIs that will be discussed in this branch, please take a look at the Pull Requests targeting it: https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Atopic-usb Regards, Carles
|
|
|
|
Re: SDK 0.11.4 Release
Stephanos Ioannidis
To elaborate, there is a critical bug in the GCC 8.3.0 (included in the Zephyr
toggle quoted messageShow quoted text
SDK 0.10.3) that causes it to emit incorrect instructions for the ARC targets. (see https://github.com/zephyrproject-rtos/zephyr/issues/26659) This issue seems to be fixed in the GCC 9.x, so we need to release a new SDK, that is compatible with the 1.14 LTS release, with GCC 9.x (or alternatively, update the 1.14 LTS so that it can be used with the latest release of Zephyr SDK, but I am not sure how feasible that would be). Stephanos p.s. another reason to use the Zephyr version number as the base for the SDK version numbers (cc @tejlmand)
-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Wu, Wentong via lists.zephyrproject.org Sent: Wednesday, July 8, 2020 1:05 PM To: Kumar Gala <kumar.gala@linaro.org>; zephyr-users@lists.zephyrproject.org; zephyr-devel <zephyr-devel@lists.zephyrproject.org>; announce@lists.zephyrproject.org Subject: Re: [Zephyr-devel] SDK 0.11.4 Release Any plan to have 1.14 LTS branch upgrading SDK as master does? IMHO, we should do that because we claim it's LTS branch. Thanks -----Original Message----- From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Kumar Gala Sent: Friday, June 26, 2020 10:46 AM To: zephyr-users@lists.zephyrproject.org; zephyr-devel <zephyr-devel@lists.zephyrproject.org>; announce@lists.zephyrproject.org Subject: [Zephyr-devel] SDK 0.11.4 Release Hi, Some minor fixes related to newlib and a packaging related fix for the individual arch toolchain packages (missing the cmake files) The SDK can be found here: https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.4 Please download and try things out and report any issues. - General: * Fixed issue with cmake files not being installed in arch specific toolchan packages - newlib: * Fix setting of -DMISSING_SYSCALL_NAMES consistent on all builds * Set march=pentium for 32-bit x86 build - k
|
|
|
|
Re: SDK 0.11.4 Release
Wu, Wentong
Any plan to have 1.14 LTS branch upgrading SDK as master does? IMHO, we should do that because we claim it's LTS branch.
toggle quoted messageShow quoted text
Thanks
-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On Behalf Of Kumar Gala Sent: Friday, June 26, 2020 10:46 AM To: zephyr-users@lists.zephyrproject.org; zephyr-devel <zephyr-devel@lists.zephyrproject.org>; announce@lists.zephyrproject.org Subject: [Zephyr-devel] SDK 0.11.4 Release Hi, Some minor fixes related to newlib and a packaging related fix for the individual arch toolchain packages (missing the cmake files) The SDK can be found here: https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.4 Please download and try things out and report any issues. - General: * Fixed issue with cmake files not being installed in arch specific toolchan packages - newlib: * Fix setting of -DMISSING_SYSCALL_NAMES consistent on all builds * Set march=pentium for 32-bit x86 build - k
|
|
|
|
Re: Post 2.3.0 PR merging
Nashif, Anas
Hi,
Here some data…
What I have just posted on slack…
So, go do some reviews please 😊
Thanks Anas
From:
<devel@...> on behalf of Carles Cufi <carles.cufi@...>
Hi Simon,
Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere.
Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged.
Carles
|
|
|
|
Upcoming Event: Zephyr Project: APIs - Tue, 07/07/2020 4:00pm-5:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 7 July 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC Where:Microsoft Teams Meeting An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18 ________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
________________________________________________________________________________
|
|
|
|
Steval drone flight control support
Brenton Chetty <brent7984@...>
Hi, I've noticed that the steval_fcu001v1 board is supported on Zephyr, however I could not find an example with the flight control software. Does anyone know if any work has been done with regards to this integration. If not, could you please point me in the right direction with regards to how to integrate flight control with zephyr. With regards Brenton
|
|
|
|
Re: Post 2.3.0 PR merging
Carles Cufi
Hi Simon,
Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere.
Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their
+1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged.
Carles
Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:
|
|
|
|
API meeting agenda: 2020-07-07
Peter A. Bigot
Carles has asked me to stand in for him again in coordinating this week's API telecon.
Topics include: https://github.com/zephyrproject-rtos/zephyr/pull/26305 adding mode flags to fs_open https://github.com/zephyrproject-rtos/zephyr/pull/26173 detecting Arduino-style reset requests on CDC-ACM I'd also like to run through the 19 items remaining in triage, moving some to To-Do, In-Progress, or On-Hold/Abandoned. I've already moved the SFDP one to In-Progress; there are others that I think no longer need to be on the to-discuss queue. Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion https://github.com/zephyrproject-rtos/zephyr/projects/18 https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit
|
|
|
|
Re: Post 2.3.0 PR merging
Simon Glass
Hi Carles, OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this. I was looking around for discussion about the decision. The closest I found was here. Is there something else? Regards, SImon
On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:
|
|
|
|
Re: [Zephyr-users] [Zephyr-devel] Post 2.3.0 PR merging
Nashif, Anas
Agreed. Those who can merge, should take 2 approvals and all other checks as a sign that it is ready to merge, no need for the approval of the person who merges, although a 3rd approval might give the PR a strong “Go”. This is actually what we agreed on 😊
Anas
From:
<users@...> on behalf of Lawrence King <lawrence.king@...>
Hi Charles:
This just my personal opinion on the subject. Two approvals is the right thing to do and what the TSC approved earlier this year.
BUT, if the second +1 is just a rubber stamp approval of the maintainer’s +1 then there is no point having two approvals.
The second +1 should come from someone who is: knowledgeable in the area, has studied the changes, and approves.
Lawrence King Principal Developer +1(416)627-7302
From: devel@... <devel@...>
On Behalf Of Carles Cufi
Sent: Monday, July 6, 2020 2:23 PM To: Simon Glass <sjg@...> Cc: devel@...; users@... Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging
Hi Simon,
A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.
That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.
I’d very much like to hear the opinion of others with merge rights in this thread.
Regards,
Carles
From: Simon Glass <sjg@...>
Hi Carles,
On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:
Perhaps given the situation this should be reversed?
Regards, Simon
|
|
|
|
Re: Post 2.3.0 PR merging
Hi Charles:
This just my personal opinion on the subject. Two approvals is the right thing to do and what the TSC approved earlier this year.
BUT, if the second +1 is just a rubber stamp approval of the maintainer’s +1 then there is no point having two approvals.
The second +1 should come from someone who is: knowledgeable in the area, has studied the changes, and approves.
Lawrence King Principal Developer +1(416)627-7302
From: devel@... <devel@...>
On Behalf Of Carles Cufi
Sent: Monday, July 6, 2020 2:23 PM To: Simon Glass <sjg@...> Cc: devel@...; users@... Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging
Hi Simon,
A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.
That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.
I’d very much like to hear the opinion of others with merge rights in this thread.
Regards,
Carles
From: Simon Glass <sjg@...>
Hi Carles,
On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:
Perhaps given the situation this should be reversed?
Regards, Simon
|
|
|
|
Re: Post 2.3.0 PR merging
Carles Cufi
Hi Simon,
A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.
That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.
I’d very much like to hear the opinion of others with merge rights in this thread.
Regards,
Carles
From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46 To: Cufi, Carles <Carles.Cufi@...> Cc: devel@...; users@... Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging
Hi Carles,
On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:
Perhaps given the situation this should be reversed?
Regards, Simon
|
|
|
|
Re: Post 2.3.0 PR merging
Simon Glass
Hi Carles, On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote: Hi all, Perhaps given the situation this should be reversed? Regards, Simon
|
|
|
|
Re: Backport NRF UART fixes to 1.14.x
#lts
Carles Cufi
Hi Ryan,
This PR is approved and marked Ready in the Backports project. This means that it will be bulk-merged with others as soon as the next release in the 1.14.x series is prepared.
If you are interested in pushing such release I’d encourage you to join the Bug triage and Release Readiness meetings on Tuesdays. You can see the details in the TSC group in lists.io:
https://lists.zephyrproject.org/g/tsc
Thanks,
Carles
From: devel@... <devel@...>
On Behalf Of Ryan Erickson via lists.zephyrproject.org
Sent: 06 July 2020 15:56 To: devel@... Subject: [Zephyr-devel] Backport NRF UART fixes to 1.14.x #lts
Looking to get this PR merged: https://github.com/zephyrproject-rtos/zephyr/pull/24245
|
|
|