[Feature Request]: better document software supply chain

[ldoolitt]

Platform

Cross-Platform

Description

Software supply chains are hard to get right. It's typically even hard to get people to agree on what "right" means. :-/
I'm a newcomer to this code base; for people like me It Would Be Nice if this code base documented what its status and desiderata are.

Let me ignore for a moment the tangle of code embedded in git submodules (just protobufs) and platform.io. There are lots of files checked into git that did not originate in meshtastic. Ideally they have an "upstream" maintainer.
Here are some obvious examples:

src/platform/stm32wl/littlefs/*
  * The little filesystem
  * lfs util functions
  * Copyright (c) 2017, Arm Limited. All rights reserved.
  * SPDX-License-Identifier: BSD-3-Clause
  #define LFS_VERSION 0x00010006
  [three minor fixes committed since 2025-03-21 import]
src/platform/stm32wl/LittleFS.h
src/platform/stm32wl/LittleFS.cpp
src/platform/stm32wl/STM32_LittleFS.h
src/platform/stm32wl/STM32_LittleFS.cpp
src/platform/stm32wl/STM32_LittleFS_File.h
src/platform/stm32wl/STM32_LittleFS_File.cpp
  * Copyright (c) 2019 hathach for Adafruit Industries
  [one minor fix committed since 2025-03-21 import]
src/platform/nrf52/softdevice/*
  * Copyright (c) Nordic Semiconductor ASA
  [two minor fixes committed since 2024-06-20 import]
src/mesh/compression/*
  * Copyright (C) 2020 Siara Logics (cc)
  * Licensed under the Apache License, Version 2.0
  [major reformatting and other minor changes since 2022-04-11 import]
src/platform/rp2xx0/pico_sleep/include/pico/sleep.h
src/platform/rp2xx0/pico_sleep/sleep.c
src/platform/rp2xx0/hardware_rosc/include/hardware/rosc.h
src/platform/rp2xx0/hardware_rosc/rosc.c
  * Copyright (c) 2020 Raspberry Pi (Trading) Ltd.
  * SPDX-License-Identifier: BSD-3-Clause
  [minor reformatting since 2024-10-08 import]
src/Fusion/*
  * @author Seb Madgwick
  [seems to come from https://github.com/xioTechnologies/Fusion]
  [no changes since 2024-06-11 import]

For each case, is the meshtastic copy a willful fork, and from where?
Should there be an effort to either merge the meshtastic changes (if any) upstream, or re-sync to upstream if/when they generate fixes or upgrades?
Should any of these be converted to a git submodule?
And maybe most important, can these choices be documented in-tree somewhere, maybe in a per-directory README.md?

[fifieldt]

Yup, agree. Work in this area welcome.

Generally we do try and fix upstream . The forks tend to be used only when upstream is abandoned or slow to merge.

[fifieldt]

How protobufs work is an area of ongoing confusion, would be good to have a developer guide. There's some stuff in the docs (in yet another repo), but not enough.