deploy: project-chip/connectedhomeip@ffbc362

project-chip · Nov 26, 2024 · 63054ab · 63054ab
commit 63054ab
Show file tree

Hide file tree

Showing 996 changed files with 523,850 additions and 0 deletions.
diff --git a/.buildinfo b/.buildinfo
@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 672e07c8e9ea26d1c75940f68632e6f3
+tags: 645f666f9bcd5a90fca523b33c5a78b7
diff --git a/.nojekyll b/.nojekyll
diff --git a/BUG_REPORT.html b/BUG_REPORT.html
diff --git a/PROJECT_FLOW.html b/PROJECT_FLOW.html
diff --git a/README.html b/README.html
diff --git a/VSCODE_DEVELOPMENT.html b/VSCODE_DEVELOPMENT.html
diff --git a/_images/CHIPTool_device_commissioned.png b/_images/CHIPTool_device_commissioned.png
diff --git a/_images/IMX-RT1170-EVK-TOP.jpg b/_images/IMX-RT1170-EVK-TOP.jpg
diff --git a/_images/Logo_RGB_H-small.png b/_images/Logo_RGB_H-small.png
diff --git a/_images/MIMXRT1060-EVKB-TOP.png b/_images/MIMXRT1060-EVKB-TOP.png
diff --git a/_images/Matter_Arch_Overview.png b/_images/Matter_Arch_Overview.png
diff --git a/_images/Matter_Layered_Arch.png b/_images/Matter_Layered_Arch.png
diff --git a/_images/RVC_app_state_diagram.png b/_images/RVC_app_state_diagram.png
diff --git a/_images/SDK_layers.png b/_images/SDK_layers.png
diff --git a/_images/cc13x4_memmap.png b/_images/cc13x4_memmap.png
diff --git a/_images/chiptool_main_screen.png b/_images/chiptool_main_screen.png
diff --git a/_images/cluster_attribute_read.png b/_images/cluster_attribute_read.png
diff --git a/_images/cluster_commands.png b/_images/cluster_commands.png
diff --git a/_images/cluster_initialization.png b/_images/cluster_initialization.png
diff --git a/_images/debug0.png b/_images/debug0.png
diff --git a/_images/debug01.png b/_images/debug01.png
diff --git a/_images/debug1.png b/_images/debug1.png
diff --git a/_images/debug_k32w1.jpg b/_images/debug_k32w1.jpg
diff --git a/_images/endpoint1_edit_pencil.png b/_images/endpoint1_edit_pencil.png
diff --git a/_images/endpoint_edit_type.png b/_images/endpoint_edit_type.png
diff --git a/_images/esp-thread-border-router-board.png b/_images/esp-thread-border-router-board.png
diff --git a/_images/factory_data_overview.png b/_images/factory_data_overview.png
diff --git a/_images/flash_driver.png b/_images/flash_driver.png
diff --git a/_images/flash_driver1.png b/_images/flash_driver1.png
diff --git a/_images/form_web.JPG b/_images/form_web.JPG
diff --git a/_images/frdm-mcxw71.jpg b/_images/frdm-mcxw71.jpg
diff --git a/_images/gdbdebugger.png b/_images/gdbdebugger.png
diff --git a/_images/import-local-repository.png b/_images/import-local-repository.png
diff --git a/_images/import-sdk-git.png b/_images/import-sdk-git.png
diff --git a/_images/import_demo.jpg b/_images/import_demo.jpg
diff --git a/_images/installed_sdks.jpg b/_images/installed_sdks.jpg
diff --git a/_images/integration_tests.png b/_images/integration_tests.png
diff --git a/_images/iwx612_2EL.jpg b/_images/iwx612_2EL.jpg
diff --git a/_images/k32w-dk6-connectors.jpg b/_images/k32w-dk6-connectors.jpg
diff --git a/_images/k32w-dk6.jpg b/_images/k32w-dk6.jpg
diff --git a/_images/k32w-se.jpg b/_images/k32w-se.jpg
diff --git a/_images/k32w1-evk.jpg b/_images/k32w1-evk.jpg
diff --git a/_images/matter_fabric_synchronization.png b/_images/matter_fabric_synchronization.png
diff --git a/_images/matter_mbedos_overview_simplified.png b/_images/matter_mbedos_overview_simplified.png
diff --git a/_images/matter_nrfconnect_overview_simplified_ncs.svg b/_images/matter_nrfconnect_overview_simplified_ncs.svg
diff --git a/_images/mcu-set.PNG b/_images/mcu-set.PNG
diff --git a/_images/mcu-set.png b/_images/mcu-set.png
diff --git a/_images/mcu-set1.png b/_images/mcu-set1.png
diff --git a/_images/mcxw71_debug.jpg b/_images/mcxw71_debug.jpg
diff --git a/_images/mcxw71_installed_sdks.jpg b/_images/mcxw71_installed_sdks.jpg
diff --git a/_images/murata_usd-M2_adapter.jpg b/_images/murata_usd-M2_adapter.jpg
diff --git a/_images/murata_usd-m2_connections_1.jpg b/_images/murata_usd-m2_connections_1.jpg
diff --git a/_images/murata_usd-m2_connections_2.jpg b/_images/murata_usd-m2_connections_2.jpg
diff --git a/_images/mw320.jpg b/_images/mw320.jpg
diff --git a/_images/mw320_console.jpg b/_images/mw320_console.jpg
diff --git a/_images/nRF52840-DK-small.png b/_images/nRF52840-DK-small.png
diff --git a/_images/nRF52840_DK_info-medium.jpg b/_images/nRF52840_DK_info-medium.jpg
diff --git a/_images/nRF52840_Dongle-medium.jpg b/_images/nRF52840_Dongle-medium.jpg
diff --git a/_images/nRF5340_DK_info-medium.jpg b/_images/nRF5340_DK_info-medium.jpg
diff --git a/_images/nRF7002-DK_Front-small.png b/_images/nRF7002-DK_Front-small.png
diff --git a/_images/new_project.jpg b/_images/new_project.jpg
diff --git a/_images/nrfconnect_android_connectivity.png b/_images/nrfconnect_android_connectivity.png
diff --git a/_images/nxp_hw_connectivity.JPG b/_images/nxp_hw_connectivity.JPG
diff --git a/_images/on_off_cluster.png b/_images/on_off_cluster.png
diff --git a/_images/ota_topology.JPG b/_images/ota_topology.JPG
diff --git a/_images/ota_topology1.JPG b/_images/ota_topology1.JPG
diff --git a/_images/power_conf.JPG b/_images/power_conf.JPG
diff --git a/_images/power_view.JPG b/_images/power_view.JPG
diff --git a/_images/rt1060_evkc_IW612_hw_rework.jpg b/_images/rt1060_evkc_IW612_hw_rework.jpg
diff --git a/_images/rt1060_evkc_IW612_hw_rework_detail.jpg b/_images/rt1060_evkc_IW612_hw_rework_detail.jpg
diff --git a/_images/rt1060_k32w061_pin_settings.jpg b/_images/rt1060_k32w061_pin_settings.jpg
diff --git a/_images/select-sdk.png b/_images/select-sdk.png
diff --git a/_images/select-sdk1.png b/_images/select-sdk1.png
diff --git a/_images/select_enabled_clusters.png b/_images/select_enabled_clusters.png
diff --git a/_images/silabs_logo.png b/_images/silabs_logo.png
diff --git a/_images/startup.png b/_images/startup.png
diff --git a/_images/startup1.png b/_images/startup1.png
diff --git a/_images/thread_credentials.png b/_images/thread_credentials.png
diff --git a/_images/toolchain.JPG b/_images/toolchain.JPG
diff --git a/_images/toolchain1.JPG b/_images/toolchain1.JPG
diff --git a/_images/toolchain2.JPG b/_images/toolchain2.JPG
diff --git a/_images/unit_testable_clusters.png b/_images/unit_testable_clusters.png
diff --git a/_images/unit_testable_clusters_all_classes.png b/_images/unit_testable_clusters_all_classes.png
diff --git a/_images/unit_testable_clusters_context.png b/_images/unit_testable_clusters_context.png
diff --git a/_images/unit_testable_clusters_driver.png b/_images/unit_testable_clusters_driver.png
diff --git a/_images/unit_testable_clusters_logic.png b/_images/unit_testable_clusters_logic.png
diff --git a/_images/unit_testable_clusters_server.png b/_images/unit_testable_clusters_server.png
diff --git a/_images/unit_tests.png b/_images/unit_tests.png
diff --git a/_images/workflow_of_casting_video_player.png b/_images/workflow_of_casting_video_player.png
diff --git a/_images/zap1.png b/_images/zap1.png
diff --git a/_images/zap2.png b/_images/zap2.png
diff --git a/_images/zap3.png b/_images/zap3.png
diff --git a/_images/zap4.png b/_images/zap4.png
diff --git a/_images/zap5.png b/_images/zap5.png
diff --git a/_images/zap6.png b/_images/zap6.png
diff --git a/_images/zap_compiler.png b/_images/zap_compiler.png
diff --git a/_sources/BUG_REPORT.md b/_sources/BUG_REPORT.md
@@ -0,0 +1,109 @@
+# Reporting bugs
+
+## Writing an effective bug report
+
+When reporting a bug, start with the question
+`What does a bug report need to tell the developer`.
+
+Generally you want the following parts covered:
+
+-   What is the problem
+
+-   How can the developer reproduce the problem (to see it for themselves), to
+    bisect when it was introduced or to find if it got fixed already.
+
+-   At what point does the problem occur
+
+-   What environment did this occur in
+
+Make sure the above items are covered and the bug is easy to review and parse:
+
+-   **Title** should clearly describe the problem. Bugs are often sorted from
+    the issue list which only contains the title
+
+-   **Logs** should generally be attachments (drag & drop or click on bottom bar
+    when entering issue text) and not inline with the issue.
+
+-   **Reproduction steps** and **environment** should be clearly highlighted. If
+    running commands reproduce the issue (very common), the commands should be
+    in a code block/script format.
+
+### Describing the problem
+
+Make sure the issue is obvious or provide a link explaining why the expected
+result is not met.
+
+Examples:
+
+-   `(Core dump) seen` is obvious since there should be no core dumps
+
+-   `Failure trying to read attribute X in cluster Y which is marked MANDATORY in the spec`
+    references the spec and describes why attribute read should succeed.
+
+-   `Failure trying to write attribute X in cluster Y, which is enabled since cluster FeatureMap enabled X and spec describes as writable.`
+    references the spec and explicitly states that an optional attribute is
+    enabled based on device status
+
+-   `Running certification test TC-A-B-C (link included) fails at step 3: test case asks for command to succeed, I get ACCESS_DENIED instead`
+    describes a pre-defined test case that is expected to pass but fails. Note
+    that full link to the test description is needed (and should be covered by
+    'how to reproduce' part)
+
+Unless manually curated (e.g. few lines showing the problem), logs should be
+always attachments and not inlined in the bug as the make the bug report too
+long.
+
+### Reproduction steps and when does the issue occur
+
+Include all steps needed to reproduce the problem. Link any supporting
+documentation.
+
+If stating something of the form `TC-A-B-C step 4 fails` then there should be a
+link to TC-A-B-C and ideally a list of the commands of each step since test
+cases may change over time.
+
+The bug report should contain all the information for a developer to reproduce
+the issue without needing to have access to CHIP Test case repository (not
+everyone does)
+
+### Environment for reproduction
+
+Assume that the developer will want to reproduce the issue and will try to
+mirror your environment to a reasonable degree. For this, at a minimum the
+platforms on which everything is running is needed.
+
+Try to provide as much information as seems relevant. At a minimum this could
+look like
+`Failed to commission nrf board using chip-tool running on linux. Used build on SHA abcde...`.
+This provides basic information (use nrf board, use chip-tool on linux, default
+build) to get started. Beyond that, you can refine if more items seem relevant:
+
+-   `Tested on TE9` or `Tested on interop branch xyz` gives a build reference
+    point. Useful when branches/tags are used instead of master branch as
+    development happens on master branch.
+
+-   `Thread devices fail, tested with qpg and efr32` shows that this seems to be
+    a general thread issue and developer can investigate on multiple of them
+
+*   `Tested with avahi-build and it passes/fails` helps the developer with
+    information of non-default builds that pass/fail to narrow down the problem
+
+*   `Passes with darwin-framework-tool and repl but fails with chip-tool` helps
+    the developer in narrowing down the problem
+
+### Additional information
+
+Providing additional information that can be helpful is encouraged. Each bug
+report is different here. Some examples:
+
+-   `This worked last week (around Jan 5) but started failing in recent master builds`
+
+-   `Specification changed this attribute from optional to mandatory so this may be the cause of the issue`
+
+-   `This issue may be related to #1234 as the same error is seen, however the reproduction steps seemed distinct enough that I opened a new issue`
+
+-   `While running this, I observed 100% CPU before the operation finally timed out`
+
+-   `While running this test, I observed device under test rebooting, logs attached.`
+
+-   `This only happens intermittently - I see it about 30% of the time`
diff --git a/_sources/PROJECT_FLOW.md b/_sources/PROJECT_FLOW.md
@@ -0,0 +1,85 @@
+## Matter Project Flow
+
+This section is intended to cover how Matter uses GitHub Projects, Issues,
+Milestones, Releases, and Branches for program/project management in the code
+repository.
+
+### Issues
+
+Matter uses issues as simple problem descriptions or feature requests. In
+general, all work contributed to the repository in the form of pull requests
+(PR) should be under the auspices of some open issue. This may seem onerous and
+in some cases duplicative, so consider these guidelines when deciding whether
+you can get away with not creating an issue:
+
+-   Trivial fixes: issues can function as TODO lists, simple reminders that
+    something should be addressed. Sometimes, though, the work required to fix
+    is smaller than the work required to write the issue.
+-   Issues intended to be addressed by a PR may not actually be fixed or may
+    regress.
+-   Issues can span PRs (as PRs should be as small as possible, but no smaller).
+-   Issues help form an important basis for release notes. Any PR that addresses
+    a problem that should have release visibility, please do open an issue.
+
+### Pull requests
+
+Pull requests should be small and address a single, specific change to the code
+base. They should be easy to review, as a "yes, that's better". Refrain from
+requesting review until all PR checks have completed successfully, lest you tire
+your reviewers.
+
+PR Don'ts:
+
+-   Don't combine unrelated changes. E.g. if the PR addresses a bug in some C
+    code, an update to the top-level .gitignore doesn't belong.
+-   Don't make stacks. E.g. if a change in a component requires a new feature or
+    even a small tweak in one or more of its dependencies, each dependency
+    change belongs in its own separate PR.
+
+### Milestones
+
+In Matter parlance, a milestone is simply a tag for an expected due date or
+release. Milestones are intended to help contributors and their managers to
+prioritize work. There are 2 types: Date-based and Release-based.
+
+#### Date-based
+
+Date-based milestones are named for their due date, typically a Friday of some
+week. Date-based milestones are normally assigned based on a guess about when
+something's likely to bubble up and get done based on current work load and
+resourcing. They are wishes, guesses.
+
+#### Release-based
+
+Release-based milestones are named for the release version and may have flexible
+or subject-to-change due dates. Release-based milestones are intended to track
+release blockers.
+
+A special "Not sure when" milestone is a marker for issues whose priority,
+scope, or blocking status have not been determined. Monthly review of these is a
+project goal.
+
+Issues without milestones are those that have yet to be considered for one of
+the above. Weekly review of new issues is a project goal.
+
+### Projects
+
+Projects are collections of issues, pull requests, and notes intended to capture
+larger efforts that don't fit in issues, have multiple-subsystems involved, or
+may span multiple milestones. We use projects 2 ways:
+
+1. To track burn down on a larger task. When constructing such a project, it's
+   important to think in terms of something that will eventually have an end,
+   i.e. a definite scope.
+2. To categorize issues, denote broader efforts without a definite time scope.
+   These projects might reflect or show burndown or percent complete, but are
+   mostly used to view where effort is going.
+
+Issues can belong to any number of projects, but should generally only belong to
+one of the task-tracking projects (the first type).
+
+### Branches, releases, and general development flow
+
+Master should always be Matter's best branch. Release branches, once cut, are
+closed for any feature work. Software fixes for release branches must first land
+on master unless demonstrably infeasible.