Hi Julien, > On Sep 25, 2023, at 17:34, Julien Grall <jul...@xen.org> wrote: > > Hi Henry, > > On 25/09/2023 07:40, Henry Wang 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.
Yes, good point. > > So I would lean towards at least restricting the number of MISRA patches we > are merging. We also need to consider a time limit so we don't end up to push > the release just because a MISRA patches broke the build. Honestly I am less worried about breaking the build as I saw nowadays committers normally run the Gitlab CI before pushing, but I 100% agree with you about the point that in current stage we need to be cautious. > I would suggest any MISRA patches should be committed by the first RC. Thank you very much for raising this good suggestion! RC1(or maybe even RC2) sounds safe. I checked the floating MISRA patches in the list, it seems that there are not so many of them, so I guess this suggestion is achievable. A side note of this is, if we made the final decision to cut the MISRA patches by RC1, we need to finish committing these series by the end of this Wednesday (Sep 27) EU time, to give OSSTest at least one day to sync the staging with master, so that we can tag the rc1. Kind regards, Henry > > Cheers, > > -- > Julien Grall
