Hi Jan, > On Sep 25, 2023, at 15:14, Jan Beulich <jbeul...@suse.com> wrote: > > On 25.09.2023 08:40, Henry Wang wrote: >> Hi Jan, >> >>> On Sep 25, 2023, at 14:32, Jan Beulich <jbeul...@suse.com> wrote: >>> >>> On 25.09.2023 03:25, Henry Wang wrote: >>>> Hi everyone, >>>> >>>> This is the reminder that we are currently in code freeze. The hard code >>>> freeze date will be in two weeks, i.e. Fri Oct 6, 2023. >>> >>> Could you further remind us about what is (not) permitted to go in during >>> this time? >> >> Sorry, my bad. From code freeze, technically only bugfixes and release >> Blockers can go in. >> >>> I also understand all commits need a release ack from now on? >> >> I think so. >> >>> (I'm sorry, we're doing releases only every once in a while, so it is >>> always good for things to be re-spelled out, i.e. even if they haven't >>> changed from earlier releases.) >> >> Actually, thanks for asking! For MISRA work... >> >> >>> 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… > > On a case by case basis, still allowing some in might be okay. You will want > to release-ack them, though. Right now I have three pending for commit which > might qualify: > xen/numa: address a violation of MISRA C:2012 Rule 8.3 > xen/hypercalls: address violations of MISRA C:2012 Rule 8.3 > xen/emul-i8254: remove forward declarations and re-order functions
Thanks for the list, your proposal sounds good to me and all release-acked. > > I'll also commit "MAINTAINERS: Remove myself as RISC-V maintainer", without > thinking that it would need a release ack. Sure, of course. Kind regards, Henry > > Jan
