Pull submodules

[mspang]

Via scripts/helpers/pull_submodules.sh

Updates:
git -C examples/common/m5stack-tft/repo log 42cadf2..42cadf2
git -C third_party/openthread/repo log 5f0e36eeb..b9a7903f1
git -C third_party/ot-br-posix/repo log 77a9156..eefef71
git -C third_party/pigweed/repo log 023f35b..34d9b07

[rwalker-apple]

should we have a blurb about what we're picking up from these updates?

[mspang]

should we have a blurb about what we're picking up from these updates?

Do you mean appending something like --pretty=oneline in the description or something manual?

[rwalker-apple]

I was thinking that some rationale would be offered, but perhaps that could be a policy for non-master branches.

[mspang]

I was thinking that some rationale would be offered, but perhaps that could be a policy for non-master branches.

Current rationale is

• m5stack-tft is out of sync between repos.conf & submodules again.
• We're not testing new changes in the dependencies unless we keep them updated (better to catch problems early).

[turon]

This should be okay, but we'll need to think about what our policy should be for updating openthread and https://github.com/openthread/ot-br-posix.git such that possilble regressions are avoided. once we have stable Thread support. Perhaps a good simulation framework such as cirque can help here. @gjc13

[rwalker-apple]

I was thinking that some rationale would be offered, but perhaps that could be a policy for non-master branches.

Current rationale is

• m5stack-tft is out of sync between repos.conf & submodules again.

Is this is addressable with use of a specific hash instead of a branch (as repos.conf is just a symlink)?

• We're not testing new changes in the dependencies unless we keep them updated (better to catch problems early).

Fair enough for master.

[mspang]

I was thinking that some rationale would be offered, but perhaps that could be a policy for non-master branches.

Current rationale is

• m5stack-tft is out of sync between repos.conf & submodules again.

Is this is addressable with use of a specific hash instead of a branch (as repos.conf is just a symlink)?

It's using specific hashes, however the hash in .gitmodules has fallen out of sync with the one in the git tree. We can certainly sync them back up without pulling everything, though.

• We're not testing new changes in the dependencies unless we keep them updated (better to catch problems early).

Fair enough for master.

[rwalker-apple]

I was thinking that some rationale would be offered, but perhaps that could be a policy for non-master branches.

Current rationale is

• m5stack-tft is out of sync between repos.conf & submodules again.

Is this is addressable with use of a specific hash instead of a branch (as repos.conf is just a symlink)?

It's using specific hashes, however the hash in .gitmodules has fallen out of sync with the one in the git tree. We can certainly sync them back up without pulling everything, though.

I think that the repos.conf workflow is unaware of the hashes, only git submodules is. That's what produces the skew. I'm suggesting that the .gitmodules file use an @ format so that the repos.conf workflow matches the git submodules workflow.

[mspang]

I was thinking that some rationale would be offered, but perhaps that could be a policy for non-master branches.

Current rationale is

• m5stack-tft is out of sync between repos.conf & submodules again.

Is this is addressable with use of a specific hash instead of a branch (as repos.conf is just a symlink)?

It's using specific hashes, however the hash in .gitmodules has fallen out of sync with the one in the git tree. We can certainly sync them back up without pulling everything, though.

I think that the repos.conf workflow is unaware of the hashes, only git submodules is. That's what produces the skew. I'm suggesting that the .gitmodules file use an @ format so that the repos.conf workflow matches the git submodules workflow.

Actually we already fixed that. That's what the "commit" lines in the .gitmodules are.

But you either need to use pull_submodules.sh to update both at the same time, or keep them in sync manually.

[andy31415]

@mspang - requires conflict fixing before merge

[github-actions]

Size increase report for "gn_nrf-example-build"

File	Section	File	VM

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

[github-actions]

Size increase report for "gn_linux-example-build"

File	Section	File	VM

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

[github-actions]

Size increase report for "nrf-example-build"

File	Section	File	VM
chip-nrf52840-lock-example.out	.text	992	992

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-nrf52840-lock-example.out and ./pull_artifact/chip-nrf52840-lock-example.out:

sections,vmsize,filesize
.text,992,992
.strtab,0,752
.symtab,0,256
[Unmapped],0,-992

[github-actions]

Size increase report for "linux-example-build"

File	Section	File	VM

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-standalone-demo.out and ./pull_artifact/chip-standalone-demo.out:

sections,vmsize,filesize

[github-actions]

Size increase report for "esp32-example-build"

File	Section	File	VM

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-wifi-echo.elf and ./pull_artifact/chip-wifi-echo.elf:

sections,vmsize,filesize