Date   

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:

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:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


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@...>
Date: Monday, 6 July 2020 at 15:41
To: Carles Cufi <carles.cufi@...>, Simon Glass <sjg@...>
Cc: "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-users] [Zephyr-devel] 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@...>
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:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


Re: Post 2.3.0 PR merging

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@...>
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:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


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:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


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,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

Perhaps given the situation this should be reversed?

Regards,
Simon 
 

Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles




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


Backport NRF UART fixes to 1.14.x #lts

Ryan Erickson
 


No reviews on PRs

Becker Markus
 

Hi Zephyr team,

 

I have had PRs to Zephyr that have been reviewed immediately and got merged rather quickly. Some PRs however are not getting a review although (or because) there are many reviewers assigned. What is the process to trigger reviews on PRs that have been around for some time with reviewers assigned, but no reviews happening?

 

According to https://docs.zephyrproject.org/latest/contribute/index.html#pull-requests-and-issues it’s to bring up the topic on the mailing list.

 

Specifically, the PRs in questions

https://github.com/zephyrproject-rtos/zephyr/pull/26193

https://github.com/zephyrproject-rtos/zephyr/pull/25627

 

BR,

Markus

 

Dr. Markus Becker

Software Engineer IoT

Global Systems - Embedded Software IoT

 

Tridonic GmbH & Co KG

Färbergasse 15

6850 Dornbirn, Austria

 

T +43 (0) 5572 395 - 45637

markus.becker@...

www.tridonic.com

Follow us
Youtube | LinkedIn | Twitter

Legal form of Company: GmbH & Co KG
Registered Office: Dornbirn
Registered No.: FN 218728 i
Register Court: Feldkirch, Austria

VAT-No.: ATU53377108

 


The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.


Re: Measuring LiPo on Adafruit nRF52 Feather

Peter A. Bigot
 

Look at samples/boards/nrf/battery, and boards/arm/thingy52_nrf52832/thingy52_nrf52832.dts which adds the voltage-divider compatible that describes the circuit connected to the ADC input.  You'll need a similar node with the resistances specific to your board.

Peter


Measuring LiPo on Adafruit nRF52 Feather

Tomas McGuinness <tomas@...>
 

Hello,

I'm quite new to Zephyr, and I have a question related to the nRF52 Adafruit Feather.

As I understand it, this board gives you the ability to measure the voltage on the connected LiPo battery using GPIO 31 (A7). 

For a small sensor project, I would like to use this measurement to report on battery level, but I cannot find any guidance on how I might read this pin's value? 

Are there any examples you would recommend I take a look at? Any help would be very much appreciated!

Regards,
Tom


Re: Dev-Review Meeting Agenda Jul 2

Kumar Gala
 

On Jul 2, 2020, at 7:15 AM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@...> wrote:

Here’s the agenda topics for this week:

* initial steps towards devicetree-based device definitions and dependency representations [@pabigot]
[ https://github.com/zephyrproject-rtos/zephyr/pull/25996 ]
Had the wrong link here, should be links to:

https://github.com/zephyrproject-rtos/zephyr/pull/26616
https://github.com/zephyrproject-rtos/zephyr/pull/26388


* stm32: devices signals configuration from dt pinctrl nodes [@erwango]
[ https://github.com/zephyrproject-rtos/zephyr/pull/25996 ]

* Any PR/issues w/dev-review tag

* Any topics anyone else has.

- k


Upcoming Event: Zephyr Project: Dev Meeting - Thu, 07/02/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 2 July 2020, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Dev-Review Meeting Agenda Jun 10

Erwan Gouriou
 

Thanks Marti for sharing!

On Wed, 10 Jun 2020 at 22:40, Bolivar, Marti <marti.bolivar@...> wrote:
"Bolivar, Marti via lists.zephyrproject.org"
<marti.bolivar=nordicsemi.no@...> writes:

> It seems like TSC moved to a new Teams meeting; will this be moving,
> too?

The meeting has moved to a new Teams home and I've been told the wiki is
up to date, for anyone interested in attending:

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-dev-meeting




Dev-Review Meeting Agenda Jul 2

Kumar Gala
 

Here’s the agenda topics for this week:

* initial steps towards devicetree-based device definitions and dependency representations [@pabigot]
[ https://github.com/zephyrproject-rtos/zephyr/pull/25996 ]

* stm32: devices signals configuration from dt pinctrl nodes [@erwango]
[ https://github.com/zephyrproject-rtos/zephyr/pull/25996 ]

* Any PR/issues w/dev-review tag

* Any topics anyone else has.

- k


Re: Bluetooth mesh and Central role simultaneously #bluetoothmesh #bluetooth

Johan Hedberg
 

Hi Andreas,

On 1. Jul 2020, at 15.47, andreas.schmidt@... wrote:
I am aware of the reduced scanning time for the mesh. It’s just that in my scenario the mesh is running all day long, and occasionally some BLE smartphone touches the device and then I need that fast ad-hoc connection.
 
With saying “LPN nodes are an exception”: do you think that the targeted coexistence with BLE Central role could be possible with a LowPower node? 

No, I don’t think that combination would make sense. One option I forgot to mention is the bt_mesh_suspend() & bt_mesh_resume() APIs. You could try suspending mesh operations (advertising & scanning) for the duration of performing what you need in central role, and then calling bt_mesh_resume() again. The effect will basically be the same as taking the mesh node out of range from the mesh network for that duration.

Johan


Re: Bluetooth mesh and Central role simultaneously #bluetoothmesh #bluetooth

Andreas
 

Hi Johan,

 

thank you very much for your help in that matter.

I am aware of the reduced scanning time for the mesh. It’s just that in my scenario the mesh is running all day long, and occasionally some BLE smartphone touches the device and then I need that fast ad-hoc connection.

 

With saying “LPN nodes are an exception”: do you think that the targeted coexistence with BLE Central role could be possible with a LowPower node? 

 

I understand that we will not have a solution for my scenario short-term, so I might really have to think about using two controllers to get started.

Overall I am quite impressed about the status of the BLE implementations in Zephyr and am looking forward to the next steps.

 

Best wishes,

Andreas

 


Upcoming Event: Zephyr Project: APIs - Tue, 06/30/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 30 June 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
 
 
________________________________________________________________________________


API meeting agenda: 2020-06-30

Peter A. Bigot
 

Carles has asked me to stand in for him in coordinating this week's API telecon.
 
Topics include:
 
- Add i2c_async for asynchronous transfers
  - 23371 https://github.com/zephyrproject-rtos/zephyr/pull/23371 - drivers: i2c: Add i2c_async for asynchronous transfers
  - Related PRs:
    - 22409 https://github.com/zephyrproject-rtos/zephyr/pull/22409 - device: device api extension proposal
    - 24781 https://github.com/zephyrproject-rtos/zephyr/pull/24781 - lib: queued_operation: add API for managing a queue of operations
    - 23075 https://github.com/zephyrproject-rtos/zephyr/pull/23075 - Asynchronous sequence manager

- 26173 https://github.com/zephyrproject-rtos/zephyr/pull/26173 - "uart: add a new "line ctrl changed remotely"
- Status update on QSPI infrastructure
  - SFDP support: https://github.com/zephyrproject-rtos/zephyr/pull/25851
  - STM32 QSPI: https://github.com/zephyrproject-rtos/zephyr/pull/25806
  - NXP iMX QSPI: https://github.com/zephyrproject-rtos/zephyr/pull/25669
 
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
 


SDK 0.11.4 Release

Kumar Gala
 

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


Zephyr: Toolchain Working Group - Thu, 06/25/2020 #cal-notice

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Zephyr: Toolchain Working Group

When:
Thursday, 25 June 2020
2:00pm to 3:00pm
(GMT+00:00) UTC

Where:
Microsoft Teams Meeting

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________