315 lines
23 KiB
Plaintext
315 lines
23 KiB
Plaintext
{
|
||
"comments": [
|
||
{
|
||
"unresolved": true,
|
||
"key": {
|
||
"uuid": "32982b65_a63335f8",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 32832
|
||
},
|
||
"writtenOn": "2024-01-15T05:41:31Z",
|
||
"side": 1,
|
||
"message": "Hi, Vefa and architects: \n I\u0027m fine with the spec. \n I have a question here which might be not necessary for the spec, but is important for our kernel developing process on this upgrading. From my work by now, I found this kernel upgrading can cause some user interface changes (e.g. attribute files change under proc/ sys/ ...) and they will cause jenkins installation failures. Those issues need to be solved or located by wrcp framework. Then it is a problem how kernel and framework work together. If we merge kernel first, it will cause broken installation. If we merge all the changes together, it will involve a mass of patches from different developers.\n Do you have any idea about how we deal with this? Will it be OK if we use a temp branch for those repos of this upgrading and merge them back when all the work finished?\n Thanks.",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": true,
|
||
"key": {
|
||
"uuid": "38913b18_b54ee416",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 33377
|
||
},
|
||
"writtenOn": "2024-01-15T20:22:46Z",
|
||
"side": 1,
|
||
"message": "Hi Li,\n\nThis is an excellent question; thank you.\n\nAn example for a way to attack this issue: During the v5.10 kernel uprevision activity, Jiping had a private StarlingX master branch project onto which she applied her patches/changes, and I used Jiping\u0027s project as a baseline for mine, by fetching from the repositories in Jiping\u0027s project. This was not very easy to work with, but we (Jiping and I) were able to pull it off.\n\nWe were aware of some of the v5.10 kernel compatibility issues (thanks to early tests) ahead of the v5.10 kernel upgrade commit getting merged, and we fixed them ahead of time. An example: https://review.opendev.org/c/starlingx/integ/+/799702\n\nAnother and likely more elegant approach, as you mention, is to have an integration branch created for this purpose. When the v6.6 kernel is ready in the integration branch, we can then merge the integration branch into the master branch in the affected repositories. The problem with this is that we will have a dependency on the StarlingX build team, as they will need to create a new branch (in all affected repositories) and a new nightly StarlingX build job for the integration branch. This will delay us a bit, but I agree that it is the \"proper\" way to go.\n\nWhen we have a consensus on how to resolve this issue, I can update the specification proposal to mention what we decided on.\n\nAll, we need feedback.\n\n---\n\nFinally, regarding incompatibilities with the v6.6 kernel, I am aware of a removed sysctl variable (\"kernel.sched_nr_migrate\") in the v6.4.3-rt kernel, which prevented Ansible bootstrap while I was verifying something else, and I patched the kernel to reintroduce this sysctl. I think that we can remove the use of \"kernel.sched_nr_migrate\" from StarlingX instead of doing what I did... ( I mentioned it here: https://review.opendev.org/c/starlingx/kernel/+/889319/1//COMMIT_MSG )\n\n---\n\nThank you,\n\nVefa",
|
||
"parentUuid": "32982b65_a63335f8",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "bf22b91a_17c4d958",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 26026
|
||
},
|
||
"writtenOn": "2024-01-16T11:54:24Z",
|
||
"side": 1,
|
||
"message": "Adding other TSC members to review.",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "d41f4f11_9189e2a1",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 26026
|
||
},
|
||
"writtenOn": "2024-01-17T14:08:29Z",
|
||
"side": 1,
|
||
"message": "Shuquan and SteveG ... can you guys +2",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "03f103cb_b8516898",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 33377
|
||
},
|
||
"writtenOn": "2024-01-23T14:00:30Z",
|
||
"side": 1,
|
||
"message": "Hi all,\n\nI started a discussion (admittedly internal to Wind River) regarding the feasibility of creating a StarlingX integration branch for the kernel upgrade activity. After about a week of waiting, I learned that the effort required for creating an integration branch is not prohibitive (likely a day\u0027s worth of work). I have not received negative or positive comments, however.\n\nIf the reviewers of this proposal find it beneficial, I can update the specification proposal to note that the use of an integration branch has been under consideration. Until then, I would like to \u0027resolve\u0027 this thread.\n\nThank you,\n\nVefa",
|
||
"parentUuid": "38913b18_b54ee416",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "e65589e8_18d85480",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 33377
|
||
},
|
||
"writtenOn": "2024-01-23T14:00:30Z",
|
||
"side": 1,
|
||
"message": "Hi all,\n\nMy understanding is that we need another vote for the approval of this specification proposal to reach a simple majority (3 approvals out of 4 possible approvers):\n\nhttps://docs.starlingx.io/governance/reference/tsc/house.html#specs-approval\nhttps://docs.starlingx.io/governance/reference/tsc/\n\nIs there any chance that another Technical Steering Committee (TSC) member could review this specification proposal?\n\nThank you,\n\nVefa",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "bf6a1de3_439a8874",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 33394
|
||
},
|
||
"writtenOn": "2024-01-25T20:37:27Z",
|
||
"side": 1,
|
||
"message": "I think the spec covers things well. As expected and the document covers we have to be concerned about kernel cmdline, /sys, /proc, and syscalls. LTP will cover lots of this as it does extensively cover syscalls via libc. The stable ABI doesn\u0027t translate to a stable API, or a stable internal ABI, so folks adding drivers may run into issues. Maybe a note should be added about this, but I am not aware of any folks adding drivers, so maybe it is overkill.",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "455caf73_46f42b77",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 33377
|
||
},
|
||
"writtenOn": "2024-01-26T16:35:53Z",
|
||
"side": 1,
|
||
"message": "Thank you, Mark. If other reviewers have any comments that would necessitate a newer revision of this commit, I can add a note to the document regarding the lack of stable kernel-internal APIs (and ABIs) that may/will cause issues for out-of-tree drivers or modules, based on your feedback. Thanks again.",
|
||
"parentUuid": "bf6a1de3_439a8874",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "4dab6f74_deae0075",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 33377
|
||
},
|
||
"writtenOn": "2024-01-26T16:39:20Z",
|
||
"side": 1,
|
||
"message": "Hi all,\n\nIs there any chance that the other Technical Steering Committee (TSC) members could review this specification proposal?\n\nShuquan Huang and Steve Geary, I would appreciate your feedback.\n\n(I have just added Steve\u0027s new account to the list of reviewers.)\n\nThank you,\n\nVefa",
|
||
"parentUuid": "e65589e8_18d85480",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "18dd79d5_0411588e",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 36731
|
||
},
|
||
"writtenOn": "2024-01-26T17:47:50Z",
|
||
"side": 1,
|
||
"message": "Reviewing it and have need for clarity in the proposal. I can\u0027t +2 it just yet. I am forming a response with points I need clarity on.",
|
||
"parentUuid": "03f103cb_b8516898",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "813bc32b_1e081f3e",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 33377
|
||
},
|
||
"writtenOn": "2024-01-26T17:55:42Z",
|
||
"side": 1,
|
||
"message": "Thank you, Steve. (I think you meant to reply to the other thread?)",
|
||
"parentUuid": "18dd79d5_0411588e",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "b918bec5_c4805828",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 36731
|
||
},
|
||
"writtenOn": "2024-01-26T20:05:34Z",
|
||
"side": 1,
|
||
"message": "My understanding of the proposal is intends to upgrade StarlingX’s kernel from a Yocto Project (YP) LTS kernel based on a 5.10 kernel.org a YP LTS kernel based on a kernel.org 6.6 kernel. While I completely support and champion adopting a new kernel to take advantage of new features and improve stability, the full picture of this proposal is unclear to me.\n\nThe Storyboard states the upgrade objective is to let StarlingX take advantage of upstream improvements made to the Linux kernel since the release of StarlingX\u0027s current kernel based on v5.10. Bullet two of proposed change states the continued use of the YP kernel as the upstream source for the StarlingX kernel.\n\nAlthough StarlingX’s kernel is sourced from YP, it is unclear how the StarlingX community gets upstream support for its own kernel. Keep in mind that YP originally sources its kernel from kernel.org and doesn’t directly support kernel.org kernel content. I would like the following addressed in the proposal:\n How the StarlingX kernel remediates StarlingX kernel defects where the code \n maintainer is kernel.org, YP, and out-of-tree drivers, respectively.\n\nI did read the relevant uplevel subsection for the StarlingX 6.0 release. Statements made in the subsection were pertinent at the time of the writing. However, progress since the original authoring suggests a different conclusion. I am not advocating that an upstream kernel sourced from Debian be considered for StarlingX 10.0. However, I do suggest that there be an update somewhere in the StarlingX ethos that revisits the topic and that the 6.0 uplevel analysis reference be removed from this, specific proposal.\n\nIf out-of-tree is relative to any other kernel besides YP, please reference the kernel. For example, “YP out-of-tree” and “StX out-of-tree” to be clear on where technical debt is being applied.",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": true,
|
||
"key": {
|
||
"uuid": "46484339_fc578fe1",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 33377
|
||
},
|
||
"writtenOn": "2024-01-26T21:15:20Z",
|
||
"side": 1,
|
||
"message": "Hi Steve,\n\nThank you for the feedback!\n\nI need to admit most of the topics you mention are beyond my vision and/or knowledge as a StarlingX contributor who happens to be employed by Wind River. I will consult with other colleagues, I will try to address your feedback with a newer revision of the specification proposal.\n\nIn the meantime, if you could clarify what you meant by (or what you were referring to with) \"However, progress since the original authoring suggests a different conclusion\", I would really appreciate it.\n\nA few notes:\n\n---\n\n\u003e Although StarlingX’s kernel is sourced from YP, it is unclear how the StarlingX community gets upstream support for its own kernel. Keep in mind that YP originally sources its kernel from kernel.org and doesn’t directly support kernel.org kernel content.\n\nI hope that I did not misunderstand, but I feel as if this is not directly within the scope of this proposal, as this proposal itself does not change the pre-existing support structure. Upstream support for the Linux kernel is, I am afraid, on a best-effort basis for members of projects like StarlingX.\n\nStarlingX community members can isolate bugs they find in the StarlingX kernel to a few different sources: StarlingX\u0027s own kernel patches layered on top of linux-yocto and linux-yocto\u0027s patches layered on top of kernel.org, and then kernel.org sources. (We can also consider the PREEMPT_RT patches inherited from linux-yocto, utilized in the low-latency StarlingX kernel, a separate \"layer\".)\n\nIf a StarlingX-specific kernel patch is found to be the culprit for an issue, then the bug should be reported on the StarlingX bug tracker on launchpad.net. That is the main support mechanism of the StarlingX community in addition to the mailing list and Matrix channels, as far as I know.\n\nIn contrast, if a bug is isolated into linux-yocto or kernel.org-specific upstream changes, then, **in addition** to the StarlingX bug tracker, **willing** community members may opt to report their findings on relevant mailing lists (such as linux-yocto@lists.yoctoproject.org for linux-yocto, and linux-kernel@vger.kernel.org and other appropriate mailing lists for kernel.org-maintained code).\n\nFollowing that bug report, fixing the actual issue is mostly a volunteer effort from the Linux kernel development community. (StarlingX does not have influence on this, as far as I know.) kernel.org\u0027s issue reporting and resolution process is discussed in depth here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html\n\nIf anyone in the StarlingX community has a need for paid/non-volunteer support, then there are companies like Wind River that can provide support and maintenance contracts.\n\nI apologize, as I am under the impression that what I stated above is already obvious to you. I believe that I need clarification regarding your ask.\n\n---\n\n\u003e How the StarlingX kernel remediates StarlingX kernel defects where the code maintainer is kernel.org, YP, and out-of-tree drivers, respectively\n\nMy current understanding is that Wind River is currently (and has been) a major contributor to StarlingX, and hence resolves most of the bugs and handles the maintenance of the StarlingX kernel and in-tree and out-of-tree device drivers shipped with StarlingX.\n\nResolving kernel issues usually involves StarlingX-specific patches, which most of the time are cherry-picks of upstream kernel.org commits. Occasionally, bugs in some of the out-of-tree drivers are fixed by the vendors providing the drivers, by releasing newer/fixed versions of the drivers, which are then pulled into StarlingX.\n\nI would like to note again that this proposal does not propose changing the aforementioned pre-existing support structure for the fixing of kernel and/or out-of-tree driver bugs.\n\n---\n\n\u003e \"If out-of-tree is relative to any other kernel besides YP, please reference the kernel. For example, “YP out-of-tree” and “StX out-of-tree” to be clear on where technical debt is being applied.\"\n\nIn the Linux kernel community, the term \"out-of-tree\" is commonly used for drivers that are not included in the mainline kernel tree released by kernel.org.\n\nMy understanding is that the linux-yocto does not include drivers additional to what kernel.org kernels provide **in the linux-yocto branches utilized by StarlingX**: vX.Y/standard/base and vX.Y/standard/preempt-rt/base.\n\nAll this to say, by out-of-tree drivers, the document was referring to the drivers in the following listing: https://opendev.org/starlingx/kernel/src/branch/master/kernel-modules\n\nThese drivers are added to StarlingX by the StarlingX community, so based on your terminology, they would constitute \"StarlingX out-of-tree\", I think. Please correct me if my understanding is wrong.\n\nIf it would be beneficial, I can clarify the meaning of \"out-of-tree\" in the next revision of this commit.\n\n---\n\nFinally, I would like to state that I am only expressing my personal understanding regarding StarlingX, Yocto Project and kernel.org-related projects. I am **not** speaking for my employer, Wind River.\n\nAgain, I would really appreciate any and all clarification you can provide regarding your asks, based on what I wrote above.\n\nThanks!\n\nVefa\n\n(I am marking this as un-resolved, as addressing these feedback items will require a revision of the specification proposal.)",
|
||
"parentUuid": "b918bec5_c4805828",
|
||
"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": true,
|
||
"key": {
|
||
"uuid": "1a94840b_2cf5a259",
|
||
"filename": "/PATCHSET_LEVEL",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 0,
|
||
"author": {
|
||
"id": 36731
|
||
},
|
||
"writtenOn": "2024-01-29T20:26:35Z",
|
||
"side": 1,
|
||
"message": "@mark.asselstine@windriver.com and vefa.bicakci@windriver.com I believe I now more completely understand. In my initial read, I could not trace kernel contexts. The StX kernel has upstream originating from kernel.org and YP and unclear on relative out-of-tree drivers. Per your responses, the StX kernel is sourced from YP which may come with OOT drivers integrated. Thus, they are not OOT as consumed by StX. This was at the heart of what I wanted to trace and now understand and am ok with.\n\nGiven the responses, I am ok with the proposal as written.\n\nI think Mark iterated closer to an associated support question that I originally asked due to my incorrect understanding about YP-related OOT drivers in StarlingX. It\u0027s not quite there but is when expanded, \"the YP community would not be interested in issues raised that would use a modified codebase from what YP produces or non-embedded use cases.\" This does not need to be addressed in this proposal.",
|
||
"parentUuid": "eedc5aac_d0b76bb8",
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "682aa0e0_e25da0c8",
|
||
"filename": "doc/source/specs/stx-10.0/approved/os-2011000-uprevision-kernel-to-v6.6.rst",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 264,
|
||
"author": {
|
||
"id": 32832
|
||
},
|
||
"writtenOn": "2024-01-15T05:41:31Z",
|
||
"side": 1,
|
||
"message": "we are expecting this spec for drivers.",
|
||
"range": {
|
||
"startLine": 262,
|
||
"startChar": 25,
|
||
"endLine": 264,
|
||
"endChar": 29
|
||
},
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
},
|
||
{
|
||
"unresolved": false,
|
||
"key": {
|
||
"uuid": "68aee5a1_ceba2e33",
|
||
"filename": "doc/source/specs/stx-10.0/approved/os-2011000-uprevision-kernel-to-v6.6.rst",
|
||
"patchSetId": 1
|
||
},
|
||
"lineNbr": 264,
|
||
"author": {
|
||
"id": 33377
|
||
},
|
||
"writtenOn": "2024-01-15T20:22:46Z",
|
||
"side": 1,
|
||
"message": "Hi Li,\n\nI intend to prepare and publish this specification proposal (for in-tree drivers) as well. I will need a bit more time.\n\nThank you,\n\nVefa",
|
||
"parentUuid": "682aa0e0_e25da0c8",
|
||
"range": {
|
||
"startLine": 262,
|
||
"startChar": 25,
|
||
"endLine": 264,
|
||
"endChar": 29
|
||
},
|
||
"revId": "8d05288efa59f8bcf1e9230bb4e68e1abceb1268",
|
||
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
||
}
|
||
]
|
||
} |