Re: Xen 4.18 release: Reminder about code freeze

[Julien Grall <julien@xxxxxxx>]

Hi Henry,

On 25/09/2023 07:40, Henry Wang wrote:
> > On Sep 25, 2023, at 14:32, Jan Beulich <jbeulich@xxxxxxxx> 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…
>
> 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.
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. I 
would suggest any MISRA patches should be committed by the first RC.
Cheers,

--
Julien Grall