specs/8d05288efa59f8bcf1e9230bb4e68e1abceb1268

{
  "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": "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"
    }
  ]
}