From 2e40e3e477406fa21456b3c54dfcd5564d88fef7 Mon Sep 17 00:00:00 2001
From: Gerrit User 33394 <33394@4a232e18-c5a9-48ee-94c0-e04e7cca6543>
Date: Fri, 26 Jan 2024 21:45:30 +0000
Subject: [PATCH] Update patch set 1

Patch Set 1:

(1 comment)

Patch-set: 1
Attention: {"person_ident":"Gerrit User 33377 \u003c33377@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_33394\u003e replied on the change"}
Attention: {"person_ident":"Gerrit User 33394 \u003c33394@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_33394\u003e replied on the change"}
---
 8d05288efa59f8bcf1e9230bb4e68e1abceb1268 | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/8d05288efa59f8bcf1e9230bb4e68e1abceb1268 b/8d05288efa59f8bcf1e9230bb4e68e1abceb1268
index aa9766a..e84b27e 100644
--- a/8d05288efa59f8bcf1e9230bb4e68e1abceb1268
+++ b/8d05288efa59f8bcf1e9230bb4e68e1abceb1268
@@ -228,6 +228,24 @@
       "revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
     },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "eedc5aac_d0b76bb8",
+        "filename": "/PATCHSET_LEVEL",
+        "patchSetId": 1
+      },
+      "lineNbr": 0,
+      "author": {
+        "id": 33394
+      },
+      "writtenOn": "2024-01-26T21:45:30Z",
+      "side": 1,
+      "message": "Steve, I am unclear what you mean by \"Keep in mind that YP originally sources its kernel from kernel.org and doesn’t directly support kernel.org kernel content.\". I think you mean that the YP community would not be interested in issues raised that would use a modified codebase from what YP produces. This is correct and typical of most projects, if you change something (fork it) you own it unless it can be show to affect things pre-fork. Anyways, please confirm that this is what you are stating as it might reflect the answers.\n\n\"How the StarlingX kernel remediates StarlingX kernel defects where the code\nmaintainer is kernel.org, YP, and out-of-tree drivers, respectively.\" - per the above effort is taken to find the correct owner which is usually the highest on the chain. You can\u0027t raise bugs or send merge requests to kernel.org if the issue doesn\u0027t exist in kernel.org, so identifying where the offending code came from directly relates to where the remediated code gets sent. As an additional wrinkle not all upstream source remain \"open\". So once the stable maintainers stop their maintenance a remediation might have to be hosted on STX or YP. This care and attention is the same if using a Debian kernel vs. YP.\n\nRegarding the kernel selection process and planning a future review using a current decision matrix, I think myself and others can get behind this 100%. I was actually reviewing slides and discussions form the time and some things on the mark, while other missed the mark.\n\nLastly, your ask about OOT kernel modules. Only the linux-yocto kernel source has been used in STX so by definition we use no OOT kernel modules for YP. Under the hood the YP linux-yocto kernel does include OOT kernel modules, however integrated, so no longer OOT. The only one present in the source branch we use is AUFS (if I recall correctly). At any rate it is find to add details to the document, but when speaking about OOT modules, these have been STX specific and not coming from the YP kernel.\n\nHopefully this helps. Vefa, Steve, let me know if we need more discussion to sort through these asks.",
+      "parentUuid": "46484339_fc578fe1",
+      "revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
     {
       "unresolved": false,
       "key": {