Hi Stefano, > On Sep 26, 2023, at 05:05, Stefano Stabellini <[email protected]> wrote: > > On Mon, 25 Sep 2023, Henry Wang wrote: >>> On Sep 25, 2023, at 18:07, George Dunlap <[email protected]> wrote: >>> On Mon, Sep 25, 2023 at 10:35 AM Julien Grall <[email protected]> wrote: >>>> On 25/09/2023 07:40, Henry Wang wrote: >>>>>> On Sep 25, 2023, at 14:32, Jan Beulich <[email protected]> wrote: >>>>>> This, for example, would then likely mean >>>>>> that all Misra work now needs queuing for after the tree re-opens ... >>>>> >>>>> …I also thought about this, to be honest I am tempted to loose the control >>>>> or at least offer some flexibility on this specific part, as normally >>>>> MISRA >>>>> related changes are harmless and actually harden the code. I am wondering >>>>> if there are any objections from others… >>>>> >>>>> Committers, would you mind sharing your opinion on this one? Thanks! >>>> >>>> I am split. On one hand, I agree they low risk and would be good to have >>>> them. But on the other hand, they tend to be invasive and may interfere >>>> with any bug we need to fix during the hardening period. >>> >>> *Theoretically* MISRA patches should have no behavioral side effects; >>> but it's quite possible that they will. I'd be in favor of a more >>> strict view, that they should all go on a separate branch (or simply >>> be reviewed in-principle and re-submitted after we branch) now that >>> the feature freeze is done. >> >> Thanks for sharing your opinion. I definitely understand your concern. I >> think in >> Xen Summit we agreed that the release process should not affect the normal >> code review, so MISRA patches can still be posted to the list and be >> reviewed. >> When the staging reopens, these staged MISRA patches can be committed right >> away. >> >>> That's my recommendation, but ultimately I'd leave the decision to Henry. >> >> Since this is about MISRA, I would like to wait one more day to see if there >> is >> any input from Stefano, otherwise I think Julien’s suggestion is very good so >> we can just follow that proposed timeline. > > I am not concerned about MISRA C patches breaking the build because > Bugseng has been running all their patches through gitlab-ci before > posting them to xen-devel. > > I agree with Jan that on a case by case basis still allowing some MISRA > C patches to be committed is okay. I think they should require a > Release-ack from Henry, so Henry (and the maintainers) can still decide > which ones are low risk enough to go in, and also limit the amount of > overall churn. This means that I expect that we are slowing down with > MISRA C commits.
+1 > > I think we should slow down further after RC1 to only few commits and we > should stop entirely at some point, maybe at RC2. I would suggest after > RC2 even the least controversial of the MISRA C fixes should not go in, > unless it is also a bug fix. And even if it is a bug fix, it would be up > to Henry to decide if it is a bug we want to fix in this release or not. This is a reasonable plan and I think this is also consistent with the idea proposed by Julien, so I am ok with it. I would like to suggest that please CC me in the relevant patches before we branch off 4.18 so that I can respond in time. Thanks! Kind regards, Henry
