Re: Xen 4.18 release: Reminder about code freeze

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 25 Sep 2023, Henry Wang wrote:
> > On Sep 25, 2023, at 18:07, George Dunlap <george.dunlap@xxxxxxxxx> wrote:
> > On Mon, Sep 25, 2023 at 10:35 AM Julien Grall <julien@xxxxxxx> wrote:
> >> On 25/09/2023 07:40, Henry Wang wrote:
> >>>> On Sep 25, 2023, at 14:32, Jan Beulich <jbeulich@xxxxxxxx> 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.

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.